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PREFACE 


This  report  is  the  product  of  a  research  effort  conducted  by  the 
School  of  Information  and  Computer  Science,  Georgia  Institute  of  Tech¬ 
nology,  on  behalf  of  the  Army  Institute  for  Research  in  Management 
Information  and  Computer  Systems  (AIRMICS) .  The  purpose  of  the  effort 
has  been  to  develop  and  offer  an  independent,  outside  review  of  the  key 
concerns  to  which  the  Army  should  address  itself  in  upgrading  its 
Automated  Manpower  and  Personnel  Resources  Management  Information 
Systems.  The  basic  intent  was  to  identify  and  examine  specific  critical 
issues  which  must  be  satisfactorily  resolved  if  the  Army  is  to  have,  in 
the  decade  of  the  80's  and  beyond,  automated  systems  which  effectively 
incorporate  present  and  emerging  systems  technology  in  meeting  Depart¬ 
ment  of  the  Army  objectives. 

Since  the  future  is  a  function  of  the  past  and  of  the  present, 
AIRMICS  administrators  understood  the  desirability  of  having  the 
research  conducted  with  some  relation  to  the  hardware,  software,  and 
other  realities  of  the  existing  information  systems  currently  found 
within  various  segments  of  the  Army  personnel  community.  As  a  result, 
arrangements  were  made  to  allow  the  researchers  to  use,  as  a  setting  and 
context  for  their  activities,  the  major  organisations  involved  in  Army 
personnel  management — in  particular,  the  US  Army  Military  Personnel 
Center  (MILPERCEN)  in  Alexander,  Va.,  as  well  as  various  major  Army  and 
DOD  activities  which  seemed  to  have  especially  high  needs  for  personnel- 
related  information.  The  latter  entities  include  such  organizations  as 
the  US  Army  Finance  and  Accounting  Center  (USAFAC),  the  Deputy  Chief  of 
Staff  for  Personnel  (DCSPERS),  the  US  Army  Management  Systems  Support 
Agency  (USAMSSA),  the  Reserve  Component  Personnel  and  Administration 
Center  (RCPAC),  and  others. 

The  researchers  would  therefore  like  to  thank  not  only  AIRMICS  (for 
its  sponsorship  of  the  effort  and  for  its  far-sighted,  large-picture 
view  of  System  Development  activities  relative  to  major  personnel  and 
human- re source  systems),  but  also  the  various  activities  that  have 
allowed  their  organizations  to  be  used  as  instruments  through  which  the 
researchers  could  be  generally  oriented  to  the  extremely  complex, 
important,  and  unique  characteristics  of  military  personnel  management. 
The  persons  from  these  organizations  who  have  helped  with  their  time, 
enthusiasm,  and  knowledge  are  too  numerous  to  name.  However,  for  the 
special  importance  of  his  hospitality  to  the  success  of  this  project,  we 
would  like  to  single  out  Brig.  General  W.  Barnes,  Director  of  the  PER- 
SINSD  Directorate  of  MILPERCEN. 

The  report  is  divided  into  two  volumes.  Volume  I  is  divided  into 
the  following  6  sections: 

Section  1  outlines  the  background  of  the  project,  and  discusses  the 
conceptual  difficulties  inherent  in  scoping  out  a  problem  so  massive  in 
relation  to  the  project  resources  and  time  available. 

Section  2  delineates  a  number  of  data  base  management  concepts 
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which  the  reaearchers  believe  to  repreaent  a  reasonable  view  of*  how  the 
Army  wiahea  to  proceed  in  the  development  of  plana  for  new  information 
syatema  to  meet  future  aunpover  management  needs. 

Section  3  reviews  the  findings  that  the  researchers  have  made  dur¬ 
ing  the  course  of  their  orientation  visits  to  the  various  organisations 
enumerated  previously,  and  identifies  what  seem  to  be  the  major 
obstacles  that  the  Army  will  face  as  it  attempts  to  make  the  transition 
from  the  present  to  the  future. 

Section  4  summarizes  the  researchers'  assessment  of  the  overall 
management  information  systems  problem  as  it  now  exists  and  discusses 
the  issues  which  must  be  resolved  before  the  Army  can  successfully 
proceed  to  upgrade  its  current  personnel  data  systems. 

Section  5  summarizes  the  work  done  at  the  Army  Human  Resources 
Management  Information  Systems  Workshop  held  in  Atlanta,  Georgia  October 
6-8,  1980. 

Section  6  sets  forth  the  conclusions  of  the  research,  identifies 
generic  issues,  outlines  research  areas  for  providing  decision  support 
data,  and  offers  recoamendations  by  the  team  based  on  the  research  and 
study  performed. 

Volume  II  contains  a  set  of  appendices  containing  data  collected 
during  the  course  of  the  study.  A  complete  listing  and  description  of 
those  appendices  is  contained  at  the  beginning  of  Volume  II. 
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SECTION  I. 

PROJECT  BACKGROUND  AND  OBJECTIVES 


The  Army  Institute  for  Research  in  Management  Information  and  Com¬ 
puter  Systems  (AIRMICS)  is  the  research  arm  of  the  U.  S.  Army  Computer 
Systems  Command.  As  a  research  group,  AIRMICS  has  a  continuing  and 
long-term  interest  in  the  development  and  demonstration  of  tools,  tech¬ 
niques,  procedures,  and  advanced  design  concepts  applicable  to  future 
management  information  systems.  This  project  falls  within  the  general 
scope  of  that  aspect  of  the  AIRMICS  mission.  Specifically,  the  need  for 
improved  interface  capabilities  within  the  Army  personnel  community 
presented  AIRMICS  with  a  problem  whose  solution  had  long  term 
implications  for  improved  database  design  throughout  Army  computer 
systems  and  concomitantly  the  possibility  for  developing  recommendations 
that  might  provide  some  near  term  relief  from  problems  affecting 
management  procedures.  This  latter  outcome  was  not  a  primary  reason  for 
undertaking  the  research,  but  it  was  considered  a  distinct  and  desirable 
by-product  of  the  study.  The  AIRMICS  group  was  first  made  aware  of  the 
need  for  a  critical  review  of  the  interface  among  Army  personnel 
databases  by  cosanunication  from  General  John  S.  Crosby,  who  was  at  that 
time  the  Director  of  Personnel  Information  Systems  (PERSIND)  at  the 
Military  Personnel  Center.  General  Crosby  was  concerned  with  the 
current  systems  dependence  on  off-line  data  transfer  for  the  purpose  of 
data  management  and  strength  reconciliation.  It  was  General  Crosby's 
wish  that  research  be  undertaken  to  determine  the  feasibility  of 
introducing  state-of-the-art  database  design  concepts  into  the  Army  per¬ 
sonnel  community  with  the  expectation  that  all  major  personnel  com¬ 
ponents  might  be  served  by  a  common  database.  Creating  a  common 
database  capability  was  seen  as  the  ultimate  answer  to  the  problem  of 
eliminating  the  need  for  extensive  off-line  transfer  of  data  and  the 
numerous  work  tapes  currently  required  for  preparing  standard  and 
special  manpower  reports.  AIRMICS  was  happy  to  comply  with  General 
Crosby's  request  for  a  study  of  the  problem  of  data  exchange  within  the 
Army  personnel  community.  As  noted  above,  it  dovetailed  well  with  their 
own  basic  mission  and  promised  a  work  product  that  had  potential  for 
improving  the  management  of  personnel  data  throughout  the  Army  by 
obtaining  insights  into  the  dynamics  and  economics  of  very  large  file 
management . 

Before  the  present  project  could  be  started  General  Crosby  was 
replaced  by  General  Barnes  as  Director  of  PERSIND.  General  Barnes 
expressed  a  similar  interest  in  the  research  effort  and  felt  that  the 
Army's  current  concern  with  mobilization  made  the  study  even  more  timely 
and  significant.  The  current  information  systems  for  managing  Army  per¬ 
sonnel  data  tend  to  be  geared  towards  peacetime  operations. 
Mobilisation  planning  baa  heightened  the  Army's  interest  in  its  capacity 
for  adjusting  its  manpower  management  systems  from  a  peacetime  to  a 
wartime  footing  with  minima  delay  and  systems  retooling.  With  respect 
to  the  present  study,  mobilization  has  had  the  effect  of  alerting  the 
AIRMICS  study  group  to  the  importance  of  keeping  in  mind  that  a  military 
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database  needs  to  have  design  features  that  allow  for  the  rapid 
expansion  of  the  number  of  personnel  it  can  handle  and  the  specific  set 
of  data  elements  to  be  maintained  for  those  personnel.  The  database 
should  also  be  amenable  to  adjusting  smoothly  to  a  variety  of  procedures 
for  creating  and  updating  records.  In  addition  to  tha  recognised  need 
for  handling  massive  amounts  of  data  to  accomplish  fairly  complex 
transactions  and  reports ,  Army  personnel  systems  need  to  be  flexible  and 
dynamic  in  their  database  structures. 

Once  this  research  study  began,  it  became  immediately  evident  that 
there  were  a  number  of  other  studies  being  conducted  within  the  Army 
personnel  community  that  had  direct  implications  for  this  effort.  Three 
of  these  deserve  special  mention.  First,  there  was  the  Master  Automa¬ 
tion  Plan  for  Military  Personnel  Systems  (MILMAP)  study  being  conducted 
by  the  Automatei  nagement  Office  (AMO)  attached  to  the  office  of  the 
Commanding  General  at  MILPERCEN.  This  study  is  exhaustively  documenting 
the  data  flow  involved  in  managing  the  soldier  throughout  the  life  cycle 
of  bis  military  career.  Work  completed  to  date  covers  the  accessioning 
and  training  of  Army  personnel.  Still  underway  is  the  study  of  the  per¬ 
sonnel  functions  of  sustenance,  distribution  and  separation.  Second, 
MILPERCEN's  Personnel  Management  Systems  Directorate  is  completing  a  two 
year  effort  to  identify  the  true  universe  of  data  that  the  Army  finds 
desirable  to  maintain  in  automated  mode.  The  focus  of  this  study  group 
has  been  on  the  elimination  of  redundancy  and  duplication  in  the  Army 
personnel  system  (ERAD).  Third,  there  are  the  Standardization  con¬ 
ferences  being  conducted  under  the  aegis  of  PERSINSD  in  an  attempt  to 
reinvigorate  the  personnel  community's  commitment  to  employing  only 
standard  data  elements  and  codes  in  their  automated  systems.  In 
different  ways  each  of  these  concomitant  study  efforts  were  seen  to  have 
important  implications  for  this  study. 

As  a  result  of  arrangements  made  by  the  Data  Management  Division  of 
PERSINSD,  staff  on  this  project  were  able  to  be  briefed  on  MILPERCEN's 
mission  and  operations.  PERSINSD  provided  the  point  of  contact  for 
helping  project  staff  in  their  efforts  to  gain  access  to  personnel  and 
activities  relevant  to  the  information  needs  of  this  study.  Meetings 
and  site  visits  within  MILPERCEN  and  at  other  Army  commands  were 
arranged  as  required.  These  contacts  and  the  documents  listed  in  the 
Appendix  provided  the  primary  sources  of  information  used  in  conducting 
Phase  One  of  the  Btudy. 

The  researchers  employed  in  the  conduct  of  the  study  comprised  a 
team  fielded  by  the  School  of  Information  and  Computer  Science  of  the 
Georgia  Institute  of  Technology  (GIT).  AIRMICS  is  physically  located  in 
the  School  of  Information  and  Computer  Science  (ICS)  on  the  GIT  campus. 
This  physical  proximity  permits  AIRMICS  and  ICS  to  enjoy  a  close  working 
relationship  which  exploits  the  strengths  of  both  organizations. 

STUDY  OBJECTIVES 

s 

the  mandate  for  this  study  was  broad  and  general.  In  brief, 
AIRMICS  was  elected  to  conduct  research  into  the  feasibility  of 
establishing  data  processing  procedures  that  vould  support  the  automated 
exchange  of  common  personnel  data  among  selected  Army  organizations.  As 
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originally  scoped  out  by  General  Crosby,  the  study  was  to  conduct 
exploratory  research  into  alternatives  for  improved  data  resource 
sharing.  In  particular,  the  objective  was  to  eliminate  undesirable  off¬ 
line  data  interfaces  and  to  delineate  the  technology  required  for  real¬ 
time,  on-line  data  exchange  throughout  the  Army  personnel  community. 

In  confronting  this  challenge,  AIRMICS  proposed  a  two  phase  study 
effort  that  would  first  assess  the  nature  of  the  interface  problem  and 
then  reconmtend  alternative  technologies  for  dealing  with  it.  Phase  One 
of  the  project  had  the  objective  of  critically  reviewing  the  current 
personnel  data  management  systems  in  place  at  MILPERCEN  and  at  other 
selected  Army  organizations  that  had  major  interfaces  with  MILPERCEN. 
Specifically,  the  research  team  proposed  examining  the  commonalities  in 
the  personnel  data  being  exchanged  in  a  framework  that  would  show  the 
general  flow  of  data  through  the  various  Army  systems  and  sub-systems 
used  for  its  management. 

Phase  One  research  activities  culminated  in  an  interim  report  to 
provide  the  Army  with  an  independent  view  of  the  automated  interface 
requirements  of  its  Manpower  and  Personnel  Data  Management  Systems. 
This  report  set  the  stage  for  the  Phase  Two  activities  of  the  project. 
Phase  Two  activities  were  mainly  analytical  and  consultative;  their 
purpose  was  to  identify  and  describe  defensible  system  modifications 
that  the  Army  should  consider  implementing  in  attaining  its  goal  of 
improved  personnel  data  exchange.  During  Phase  Two,  project  staff 
capabilities  were  amplified  by  the  use  of  consultants  from  business, 
government,  and  academia.  Using  the  Phase  One  report  as  their  point  of 
departure,  these  consultants  were  asked  to  supply  regular  project  staff 
with  the  benefit  of  their  thinking  on  how  the  Army  can  best  automate  its 
personnel  data  interfaces. 

This  final  report  for  the  project  is  a  synthesis  of  staff  recommen¬ 
dations  for  developing  a  comprehensive  framework  for  planning  a  tech¬ 
nologically  realistic  and  appropriate  approach  for  accomplishing  the 
needed  integration  of  the  Army's  overall  personnel  management  informa¬ 
tion  system. 
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SECTION  II. 


DATABASE  MAMACnmrr  COALS  FOR  ARMY  PKBSnmrei,  SYSTEMS 

By  their  very  nature,  military  personnel  sysems  must  be  large  and 
complex.  Automating  such  systems  represents  a  technological  challenge 
of  the  highest  order.  In  the  case  of  the  peacetime  United  States  Army, 
for  example,  an  automated  personnel  system  must  be  capable  of  storing 
detailed  records  on  upwards  of  three  quarters  of  a  million  persons  on 
which  hundreds  of  thousands  of  transactions  per  month  must  be  performed. 
In  a  mobilization  environment,  these  numbers  will  be  expanded  by  a  fac¬ 
tor  of  3  or  more.  Because  Army  personnel  are  highly  transient,  in  terms 
of  accessions,  transfers  and  separation,  the  personnel  management  system 
must  also  be  highly  responsive  to  manpower  planning  and  information 
requests  in  order  to  ensure  compliance  with  levels  of  strength 
authorized  and  budgeted  by  the  legislature. 

The  mere  creation  and  maintenance  of  a  database  of  these  dimensions 
is  a  monumental  task  which  offers  a  vigorous  challenge  to  state-of-the- 
art  technology.  Yet  modern  management  needs  place  even  further  demands 
on  the  system:  the  system  must  be  able  to  manage  individual  ser¬ 
vicemen's  careers;  to  provide  commanders  at  many  levels  with  timely  and 
reliable  manpower  reports;  to  supply  planners  and  analysts  with  data  for 
modeling  and  other  sophisticated  analyses  of  staffing,  training,  and 
fiscal  requirements. 

The  purpose  of  this  section  of  the  report  iB  to  describe  the  struc¬ 
ture  and  function  of  the  Army  personnel  systems  in  terms  of  the  "ideal" 
systems  technology  needed  to  support  those  systems.  (The  technology  to 
be  considered  is  "ideal",  not  in  the  sense  that  it  does  not  yet  exist, 
but  in  the  sense  that  it  is  not  yet  universally  in  place  within  the  Army 
personnel  community.)  Sources  of  information  for  this  section  were 
interviews  held  with  various  Army  data  managers  and  end-users,  along 
with  the  analysis  of  a  number  of  documents  and  papers  supplied  to  the 
researchers  by  Army  personnel  and  national  information  services. 
Database  considerations  presented  herein  realistically  reflect  currently 
perceived  goals  of  the  Army  personnel  system  to  the  extent  that  these 
sources  can  convey  them  in  a  time  of  international  turmoil. 

This  section  of  the  report  therefore  presents  a  view  of  the  Army's 
own  objectives  for  its  Manpower  and  Personnel  Data  Management  Informa¬ 
tion  Systems.  In  the  opinion  of  the  research  team,  that  is  the 
appropriate  framework  for  considering  the  automated  data  interfaces 
which  are  the  direct  object  of  study  in  the  project.  It  is  seen  as  the 
proper  basis  for  considering  the  value  and  need  of  any  specific  proposed 
interface.  It  elevates  the  entire  study  effort  above  the  level  of 
considering  and  proposing  interface  procedures  that  are  little  more  than 
patches  on  the  current  operating  systems.  (The  Army  has  sufficient 
capable  personnel  to  accomplish  such  objectives  without  the  need  of 
outside  consultants.)  The  purpose  of  this  study  clearly  indicated  a 
desire  for  e  more  radical  approach  to  the  interface  problem,  one  which 
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would  touch  directly  on  tho  design  factors  which  would  resolve  the 
interface  problem  not  as  it  exists  today  bnt  as  it  will  exist  in  the 
future  technology  ...  a  technology  which  the  Army  has  no  real  option 
but  to  embrace.  Clearly,  this  means  that  one  outcome  of  this  study  must 
be  to  provide  current  data  managers  with  additional  support  in  their 
quest  for  hardware,  software,  and  organizational  modernization  to 
achieve  a  computer  communications  environment  commensurate  with  the 
responsibilities  they  bear. 

The  Army  personnel  community  is  characterized  by  a  necessary  diver¬ 
sity  in  personnel  system  requirements,  levels  of  management  and 
geographic  locations.  Partly  because  of  command  philosophy  and  partly 
due  to  practical  necessity,  a  certain  measure  of  decentralization  has 
come  to  pervade  the  systems  by  which  the  Army  personnel  resources  are 
managed.  At  the  same  time,  the  need  for  an  appropriate  degree  of 
centralization  has  come  to  be  recognized  as  essential  for  the  efficient 
management  of  manpower  resources.  The  specific  form  centralization 
should  take  and  the  manner  in  which  it  should  be  implemented  should 
remain  a  matter  of  continuing  discussion  throughout  the  Army.  Automated 
personnel  systems  are  acknowledged  to  have  the  potential  for  increasing 
centralized  control  and  management  of  personnel  resources.  The  trans¬ 
formation  of  MILPERCEN  from  a  basically  archival  activity  into  the  vital 
personnel  center  it  has  become  over  the  years  gives  tacit  evidence  of 
the  trend  towards  centralization  which  automation  has  bought  to  the 
military  personnel  community. 

While  there  is  some  question  as  to  the  degree  to  which  the  Army,  in 
its  MILPERCEN  operations,  has  successfully  centralized  its  manpower  and 
personnel  data  support  systems,  a  legitimate  issue  can  be  raised  concer¬ 
ning  the  wisdom  and  practicality  of  pursuing  centralization  to  the  point 
where  the  processing  of  personnel  data  is  totally  monolithic.  The  very 
immensity  of  this  task  from  a  data  processing  point  of  view,  if  from 
none  other,  makes  it  a  questionable  goal.  Currently,  there  are  critics 
who  claim  that  the  present  system  is  already  over-centralized  to  the 
point  where  it  will  simply  not  operate  in  a  wartime  environment.  No 
comment  is  necessary  on  the  seriousness  of  this  claim  for  a  major 
military  arm  of  the  Defense  Department.  Even  if  one  puts  the  best 
construction  possible  on  the  effectiveness  of  the  present  personnel 
system,  the  existence  of  the  SIDPERS-Vartime  study  group  stands  as  wit¬ 
ness  to  the  fact  that  MILPERCEN  can  go  on  a  wartime  footing  only  by 
drastically  reducing  the  personnel  data  items  handled.  The  problem  of 
how  successfully  it  can  convert  its  systems  to  operate  in  the  S1DPERS 
wartime  mode  is  being  studied  and  tested  with  field  trials. 

Whatever  one's  position  on  the  desirability  of  taking  system 
centralization  to  its  logical  extreme,  there  seems  little  doubt  that  the 
Army  personnel  system  must  be  an  integrated  and  coordinated  system.  At 
the  moment  this  remains  a  distant  goal  of  the  Army  personnel  system. 
While  many  headquarters  manpower  functions  have  been  consolidated,  the 
Army  still  lacks  that  degree  of  commonality  in  its  data  bases  which  will 
allow  it  to  tie  manpower  management  activities  at  low  levels  into  the 
budget  process  at  DA  level.  A  recent  GAO  study  confirms  this  deficiency 
in  the  Army  personnel  system  and  has  reconmended  that  the  Army  move 
promptly  "to  integrate  manpower  management  activities  at  all  levels." 
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No  one  in  the  Army  denies  the  imperfections  in  their  manpower  and 
personnel  management  systems.  What  seems  to  be  lacking  is  the  wil¬ 
lingness  to  charge  a  single  organisational  unit  with  the  responsibility 
for  managing  all  manpower  information  functions.  Under  the  current 
system  there  are  many  examples  of  praiseworthy  efforts  on  the  part  of 
individual  conmands  to  facilitate  manpower  and  personnel  interfaces 
among  different  organizations.  The  GAO  report,  however,  is  critical  of 
this  piecemeal  approach  to  resolving  manpower  utilization  and  accounting 
within  the  Army.  Instead,  the  GAO  firmly,  almost  stringently,  recom¬ 
mends  that  the  Army  move  promptly  to  establish  the  common  data  base 
which  alone  will  enable  the  Army  to  interrelate  all  aspects  of  the  man¬ 
power  management  process  (civilian  and  military) .  Without  such  an 
integrated  system,  the  Army  will  continue  to  be  unable  to  aggregate  man¬ 
power  needs  according  to  budget  categories,  directly  relate  manpower  to 
workload,  trace  budget  changes  to  the  detail  level,  and  evaluate  man¬ 
power  utilization.  Finally,  according  to  the  GAO  report,  an  integrated 
personnel  data  system  will  give  the  Army  a  "defined  structure  for  set¬ 
ting  goals,  acquiring  needed  information,  and  establishing 
accountability  to  compare  performance  with  goals." 

The  GAO  report  clearly  indicates  that  there  may  be  political 
obstacles  hindering  the  development  of  an  integrated  manpower  and  per¬ 
sonnel  system  within  the  Army.  (While  such  concerns  are  outside  the 
scope  of  this  project,  they  have  been  mentioned  because  they  impact  on 
any  timetable  that  might  be  prepared  for  consolidating  current  Army  per¬ 
sonnel  databases  into  an  integrated  system).  Political  considerations, 
however,  need  not  impact  negatively  on  efforts  to  conceptualise  the 
steps  which  would  have  to  be  taken  if  the  decision  were  made  to  develop 
an  integrated  system.  Nor  should  political  considerations  have  much 
relevance  for  discussion  and  research  into  the  best  design  factors  to 
incorporate  into  such  a  system.  Indeed,  a  systems  engineering  program 
to  research  those  issues  might  prove  to  be  an  effective  mechanism  for 
encouraging  the  Army  to  resolve  any  political  or  organisational  problems 
currently  standing  in  the  way  of  making  such  a  system  operational.  In 
that  vein,  it  was  the  opinion  of  this  research  team  that  attention 
should  be  focused  on  the  computer/coimaunications  needs  (hardware  and 
software)  that  will  have  to  be  met  if  the  Army  is  to  integrate  its  per¬ 
sonnel  databases.  Developing  plans  and  procedures  for  improving  its 
systems  technology  can  only  be  expected  to  impact  favorably  on  any 
negative  organizational  structures  presently  recognized  as  impeding 
technological  progress. 

This  approach  also  has  the  virtue  of  responding  to  the  expressed 
needs  of  middle  management  throughout  the  various  organizations 
currently  charged  with  managing  Army  personnel  data.  Most  of  them  are 
quite  conversant  with  the  latest  technology  and  are  eager  to  incorporate 
its  products  into  their  operational  systems.  If  one  were  to  ask  why 
they  are  not  now  making  more  headway  in  integrating  operations,  one 
would  have  to  remember  that  they  do  not  now  have  the  mass  storage 
capability  for  economically  and  successfully  managing  very  large  on-line 
data  bases.  Until  they  have  the  tools  to  establish  and  maintain  an 
integrated  system,  with  data  distributed  in  a  centrally  controlled  man¬ 
ner  rather  than  the  current  decentralized  manner,  it  is  unfair  to  be 
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critical  of  their  reliance  on  off-line  interfaces  and  uncoordinated 
processing  cycles  with  the  resultant  inconsistency  among  databases. 
There  is  really  no  other  way  for  them  to  operate. 

In  that  regard,  the  research  team  was  most  favorably  impressed  with 
the  degree  of  foresight  into  future  ADP  systems  design  manifested  by  the 
present  managers  of  the  Army  personnel  databases.  In  previous  places  of 
this  report,  mention  has  been  made  of  the  number  of  planning  studies 
currently  underway.  These  studies  have  direct  bearing  on  the  task  of 
bringing  improved  integration  into  the  systems  used  to  manage  manpower 
and  personnel  data.  They  show  a  definite  sensitivity  to  the  needs  of 
end-users  of  the  data  and  a  willingness  to  make  the  systems  carry  out 
the  varied  and  demanding  procedures  the  systems  have  been  tasked  to  per¬ 
form.  Where  there  is  dissatisfaction  with  the  systems,  that  disappoint¬ 
ment  is  shared  by  the  data  managers.  In  most  instances,  the  root  of  the 
difficulties  with  the  present  systems  can  be  traced  to  the  necessity  of 
working  with  outmoded  hardware  and  the  software  limitations  imposed  by 
that  hardware.  (Other  reports,  such  as  those  developed  by  President 
Carter's  Reorganization  Project  for  Federal  Data  Processing,  have  dealt 
in  depth  with  the  jungle  of  regulations  imposed  on  the  acquisition 
process.  This  jungle  is  the  principal  cause  of  obsolescent  and  archaic 
systems  such  as  those  operated  by  MILPERCEN.) 

In  sum,  there  is  much  interest  in  what  state-of-the-art  technology 
would  do  for  managing  Army  manpower  and  personnel  data.  They  are  plan¬ 
ning  for  a  future  which  includes  mainframe  computers  with  large  capacity 
mass  storage;  micro  and  minicomputer  capabilities  to  assist  with  data 
capture  and  local  automated  preprocessing  of  data  input;  redesign  of 
database  management  systems  (initially  for  query  and  reporting,  but 
ultimately  for  updates  and  consaunication  with  other  systems);  increased 
use  of  microfiche  storage  of  historical  records  (automatically 
retrievable);  wide  use  of  word  processing,  screen  input  and  output  of 
data  records,  and  graphics  at  the  end-user  level;  and  software  that  is 
table-driven  and  independent  of  specific  hardware. 

The  standard  goals  and  objectives  for  operating  an  integrated 
database  management  system  are  well-known  and  readily  available  from 
many  information  sources.  The  bibliography  attached  to  this  report 
provides  many  references  to  the  literature  on  DBMS.  For  the  purpose  of 
this  research  what  is  needed  is  a  brief  statement  of  the  Army  Personnel 
Management  goals  to  be  accomplished  by  a  wider  application  of  DBMS  tech¬ 
nology.  It  should  be  understood,  of  course,  that  the  basic  goals  and 
objectives  of  the  Military  Personnel  Data  Management  function  remain  the 
same  whether  DBMS  or  any  other  technology  is  employed  to  support  that 
function.  What  changes  with  the  technology  is  mostly  the  manner  in 
which  the  functions  are  implemented.  Computer  technology  mainly  changes 
processes  from  a  manual  operational  state  to  an  automated  state  with 
attendant  security  and  data  integrity  benefits. 

In  large  measure,  current  Army  personnel  functions  have  already 
been  converted  to  automated  procedures.  The  promise  of  DBMS  is  to 
continue  the  trend  to  fuller  automation,  with  an  emphasis  on  upgraded 
database  structures  and  the  automated  exchange  of  data  between 
geographically  separated  sites.  In  general,  changes  in  these  directions 
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imply  a  commitment  to  tha  acquisition  of  the  hardware  which  will  support 
the  on-line  storage  of  massive  amounts  of  data  (estimated  from  12  to  18 
billion  characters  for  current  peacetime  requirements)  and  the  com¬ 
munications  equipment  necessary  to  support  highly  active  update 
procedures  as  well  as  the  sharing  of  large  segments  of  the  master 
database. 

A  sometimes  less  obvious,  but  perhaps  even  more  critical,  comnit- 
ment  must  also  be  made  to  the  development  of  the  sophisticated  software 
required  for  operating  a  complex  network  of  data  processing  sites.  Com¬ 
mercially  available  software  may  be  used  for  this  purpose,  but  these 
packages  must  often  be  tailored  to  individual  applications  at  some  cost 
to  the  using  organizations.  As  noted  previously,  consideration  must  al¬ 
so  be  given  to  management  changes  that  will  inevitably  be  required  to 
establish  the  kind  of  centralised  control  needed  for  operating  DBMS 
networks.  Without  such  centralized  control,  it  is  unlikely  that  the 
Army  personnel  management  process  will  ever  satisfactorily  achieve  the 
ability  to  amalgamate  mission  needs,  career  needs  of  individuals,  and 
total  force  needs. 

As  noted  earlier,  there  is  nothing  offical  about  the  following 
statement  of  the  database  management  goals  for  the  Army's  personnel 
systems.  The  statement  represents  the  research  teams's  summary  of 
information  from  many  sources.  The  intent  is  not  to  lay  down  a  blue¬ 
print  for  the  future,  but  to  introduce  for  discussion  the  various  issues 
which  must  be  legitimately  considered  if  DBMS  procedures  are  to  be 
introduced  into  the  Army's  management  and  personnel  data  systems. 
Hereinafter  the  system  whose  goals  are  being  stated  here  will  be 
referred  to  as  AFDBMS,  meaning  the  Army  Personnel  Database  Management 
System. 

A.  General  System  Characteristics. 

*  The  APDBMS  should  be  designed  to  operate  in  a  total  force 
management  environment  tailored  to  satisfy  both  peacetime  and 
wartime  requirements. 

*  The  APDBMS  should  support  all  Army  personnel  data  management 
requirements  and  function  with  a  high  level  of  integration  and  com¬ 
monality  in  its  data  base  structure  and  its  system  operations 
procedures. 

*  The  APDBMS  should  be  modular,  allowing  for  the  addition  or  dele¬ 
tion  of  equipment  or  systems  software  without  major  redesign  or 
degradation  of  processing  capabilities. 

♦The  APDBMS  should  facilitate  editing  data  at  its  source,  storing 
data  where  it  is  to  be  used,  thereby  providing  end-uaers  with 
controlled  query  and  update  capabilities. 

*  The  APDBMS  should  have  network  capabilities  allowing  it  to  have 
an  automated  interface  with  other  major  data  systems,  such  as 
JUMPS. 
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*  The  APDBMS  should  be  centrally  managed  so  that  it  will  operate 
under  enforceable  standards  that  will  prevent  the  distribution  of 
data  stores  and/or  functions  to  degenerate  into  unmanageable 
congeries  of  ad  hoc  and  individualistic  procedures  within  separate 
commands. 

*  The  APDBMS  should  minimise  data  redundancy  and  eliminate  any 
necessity  for  special  conversion  routines  to  transfer  data  from  one 
site  to  another. 


B.  Specific  Life  Cycle  Data  Management  Requirements. 

The  Army  manpower  and  personnel  data  management  system  has  been 
conceptualized  on  a  model  that  embodies  the  life  cycle  of  a  military 
career.  The  five  stages  of  this  life  cycle  model  are  accession, 
training,  sustenance,  distribution,  and  separation  (where  separation  is 
generally  a  non-terminating  function  which  includes  considerations  of 
retirement,  survivors,  etc.)  At  each  stage  of  the  life  cycle  the  per¬ 
sonnel  data  management  system  is  required  to  perform  certain  functions 
that  are  more  specific  than  the  general  requirements  discussed  above. 
Basically,  as  a  manpower  as  well  as  a  personnel  data  system  the  APDBMS 
should  have  the  following  two  overriding  management  features. 

1.  Sub-systems  for  accurately  allocating,  controlling,  and  account¬ 
ing  for  Mnpower  requirements  end  resources. 

2.  Sub-systems  with  the  capacity  for  collecting,  analyzing,  project¬ 
ing  and  displaying  various  types  of  workload  and  productivity  data. 

Within  each  phase  of  the  career  life  cycle,  there  are  other 
specific  sub-system  requirements  which  the  APDBMS  must  meet.  These  are 
described  next.  The  functions  listed  under  each  life  cycle  phase  are 
not  intended  to  be  complete  and  exhaustive.  They  are  included  in  this 
report  to  illustrate  and  exemplify  the  complexity  and  extensiveness  of 
the  personnel  management  functions  demanded  of  a  military  system. 

a.  Accessions. 


*  Provide  an  automated  capability  to  recruit  the  most  qualified  in¬ 
dividuals  to  satisfy  current  and  projected  requirements. 


*  Apply  projected  resources  against  personnel  requirements  to  create 
a  recruitment  quota  baak. 


•  Track  accessions  in  a  way  that  allows  end-strength  reporting  accor¬ 
ding  to  approved  budget  levels  and  categories. 


*  Insure  single  source  data  capture  for  all  gains  to  the  naster  per¬ 
sonnel  database  and  per serve  that  data. 
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b.  Training. 

*  Establish  an  integrated  system  for  developing  and  coomunicating 
training  requirements  and  quotas. 

*  Support  a  sub-system  for  developing  optimal  training  schedules* 

*  Maintain  a  centralized  on-line  data  bank  of  education  and  training 
requirements,  programs,  and  resources. 

c.  Sustenance. 

*  Provide  automated  support  for  the  several  Army  promotion  systems. 

*  Monitor  reenlistement  bonus  funds. 

*  Operate  a  sub-system  for  reporting  combat  zone  casualty  statistics. 

*  Insure  that  Guard/Reserve  participation  data  are  available  for 
evaluation  processes. 

*  Record  award  and  decoration  data. 

*  Maintain  timely  data  relevant  to  leave,  pay,  and  dependent  statue. 

d.  Distribution. 

*  Provide  automated  support  to  Army  programs  for  job  classification, 
duty,  assigount,  and  career  development. 

*  Maintain  an  automated  manning  and  distribution  system  for  job 
definition,  job  option  offers,  and  job  performance  criteria. 

*  Provide  an  automated  resource  for  matching  individual  career  needs 
with  Army  staffing  needs. 

*  Provide  Army  managers  with  on-line  authorised  and  assigned 
statistical  data. 

e.  Separation. 

*  Integrate  the  active  duty  separation  process  with  with  the 
appropriate  Guard  or  Reserve  accession  process. 

*  Provide  Army  managers  with  information  needed  for  decisions  related 
to  loss  statistics. 

*  Supply  Army  planners  and  modelers  with  data  needed  in  using  force 
structure  models. 

*  Suport  the  Army's  capability  for  analyzing  assigned  strength  in 
order  to  accurately  project  end  strengths,  training  requirements,  and 
recruiting  requirements. 
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The  goals  and  objectives  outlined  above  for  an  Army  manpower  and 
personnel  database  management  system  clearly  demonstrate  the  magnitude 
of  the  task  involved  in  integrating  such  diverse  and  data  rich  func¬ 
tions.  Persons  familiar  with  database  management  systems  will  recognize 
the  problems  to  be  faced  in  designing  a  DBMS  capable  of  handling  the 
job.  They  will  be  particularly  sensitive  to  the  fact  that  DBMS  concepts 
have  become  popular  because  of  the  ease  with  which  classes  of  data  can 
be  retrieved  using  a  DBMS.  Vhat  needs  to  be  remembered,  however,  is 
that  this  facility  is  purchased  at  a  price  at  the  other  end  of  the  data 
processing  cycle;  namely,  that  DBMS  has  a  greater  overhead  in  time  and 
space  for  updating  and  maintaining  the  data  in  a  system.  In  the  case  of 
a  military  system,  there  are  also  the  complicating  factors  of  size  and 
activity  as  well  as  the  need  to  process  data  both  at  the  individual 
record  level  and  at  the  total  force  level.  In  other  words,  some  Army 
managers  need  complete  information  about  the  individual,  while  others 
are  interested  in  statistical  factors  about  the  entire  force.  It  will 
be  difficult  to  design  a  data  structure  that  is  equally  facile  in  ser¬ 
ving  these  diverse  needs  simultaneously. 

Of  course  these  known  needs  are  constantly  modulated,  mixed,  and 
magnified  by  the  winds  of  government  change.  Hence,  there  are  further 
characteristics  which  must  be  envisioned  for  an  Army  personnel  database 
management  system.  These  are  (1)  security  and  (2)  the  need  to  provide 
for  system  change  in  response  to  policy  and  operational  shifts. 
Security  does  not  pose  too  difficult  a  problem.  Most  database 
management  systems  have  excellent  features  for  controlling  and  auditing 
access  to  data  and  for  preventing  unauthorized  personnel  from  tampering 
vitb  the  database.  As  a  military  organization,  the  Army  is  already 
security  conscious,  and,  unlike  civilian  organizations  undertaking  to 
place  their  personnel  systems  under  a  DBMS,  the  Army  should  have  no 
particular  problem  in  installing  appropriate  security  provisions  for 
data  access. 

System  changes  in  a  large  bureaucratic  setting  such  as  a  modern 
army  are  normally  a  time-consuming  and  intricate  process.  There  are 
usually  many  layers  of  authority  through  which  a  proposed  change  must 
travel.  In  an  integrated  DBMS  environment,  this  process  is  further  com¬ 
plicated  by  the  fact  that  even  e.  relatively  straightforward  change  may 
have  impacts  that  will  affect  the  system  at  many  different  points. 
Change  in  this  data  processing  mode  must  be  carefully  evaluated  for 
system  impacts  and  provision  must  be  made  for  all  systems  effects  of  a 
change.  Fortunately,  DBMS  systems  are  so  intrinsically  complex  that 
they  can  not  be  successfully  operated  without  automated  dictionary  and 
directory  tools.  For  this  reason,  change  is  often  managed  more  success¬ 
fully  in  these  systems  than  in  tape-driven,  file-oriented  systems  where 
sloppy  documentation  can  be  more  easily  tolerated.  Nonetheless, 
responsiveness  to  database  changes  most  remain  an  important  design 
consideration  for  an  Army  personnel  DIMS  inasmuch  as  system  changes  can 
be  anticipated  as  a  somewhat  regular  system  requirement. 
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SECTION  III. 


REVIEW  OF  COTEMT  ARMY  PERSONNEL  DATA  SYSTEMS  INTERFACES 

This  section  of  the  report  discusses  the  current  status  of  the 
Army's  personnel  data  interfaces.  In  general,  data  transfer  currently 
takes  place  off-line,  with  files  being  updated  in  batch  mode  according 
to  schedules  mandated  by  the  data  needs  of  the  various  information  sub¬ 
systems  being  supported.  Insofar  as  possible,  AUTODIN  is  used  to  trans¬ 
fer  data  across  different  geographical  sites.  There  are  some  instances, 
however,  where  tapes  are  mailed  or  sent  by  courier.  Within  the  SIDPERS 
system  punch  cards  are  still  used  as  a  transfer  medium  for  some  transac¬ 
tions. 


When  AIRMICS  first  considered  the  Army  military  personnel  data 
information  system  as  a  suitable  arena  in  which  to  research  the  develop¬ 
ment  of  DBMS  concepts  in  the  Army  environment,  it  had  been  given  the 
impression  that  MILPERCEN  and  other  Army  organizations  handling  person¬ 
nel  data  were  using  some  type  of  DBMS  to  support  their  applications 
programming.  AIRMICS  understandably  viewed  the  interface  requirement  as 
a  technical  problem  involving  the  need  for  linking  major  databases  into 
a  communications  network.  In  addition  to  the  lack  of  communications, 
AIRMICS  anticipated  that  there  were  problems  with  the  consistency  and 
proponency  of  data  elements  used  in  the  Army  personnel  community.  As 
initially  envisioned,  these  were  to  be  the  problems  tackled  by  the  study 
group.  The  solution  was  to  take  the  general  form  of  employing  automated 
tools  for  data  definition  and  systems  documentation.  These  activities 
were  to  be  followed  by  the  design  and  field  testing  of  a  communications 
interface  between  MILPERCEN' s  master  personnel  database  and  the 
databases  of  other  selected  Army  organizations,  such  as  the  JUMPS 
database,  RCPAC's  personnel  master  file  of  reservists,  and  the  Base 
level  personnel  files  maintained  at  two  or  three  SIDPERS  field  instal¬ 
lations. 

Consulation  with  MILPERCEN  staff  revealed  that  AIRMICS  was  working 
under  a  set  of  assumptions  that  were  in  fact  incorrect.  The  only  role 
being  played  by  DIMS  in  the  Army  personnel  community  was  the  use  of 
System  2000  to  support  limited  real-time  queries  to  MILPERCEN' s  OMF/EMF 
master  files.  It  was  also  learned  that  while  System  2000  responds  well 
to  requests  for  individual  records,  it  functions  poorly  for  statistical 
and  tabular  inquiries.  For  that  type  of  request,  ODIS  (Overnight  Data 
Information  System)  had  been  developed  to  batch  information  requests 
which  are  run  nightly  not  against  the  System  2000  database,  but  against 
a  compressed  tape  version  of  the  OMF/EMF.  It  was  also  learned  that 
System  2000  inquiries  must  be  processed  separately  aginst  the  OMF  and 
EMF  databases,  since  there  is  no  interface  linking  them. 

Later  in  the  course  of  the  study,  it  was  learned  that  processing 
under  DBMS  technology  was  equally  absent  in  the  other  concerned  Army 
organizations.  The  case  of  RCPAC  is  probably  typical.  This  organiza- 
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tion  possesses  a  complete  DBMS  software  package,  including  DATAMANAGER 
(a  Data  Dictionary/  Directory),  TOTAL  (a  DBMS),  and  ENVIRON-1  (a  Com¬ 
munications  Control  Package).  At  the  moment,  however,  no  integral 
aspect  of  RCPAC's  personnel  data  processing  is  being  carried  out  with 
these  tools.  The  utilization  of  this  technology  must  await  certain 
equipment  additions  and  replacements.  In  the  meantime,  a  planning  group 
has  been  formed  to  determine  the  systems  design  work  that  will  be 
required  prior  to  implementing  DBMS.  The  present  expectation  of  this 
group,  however,  is  that  DBMS  will  be  used  only  for  query  and  not  for 
update. 

Clearly,  then,  currant  data  management  procedures  in  the  Army  per¬ 
sonnel  data  community  are  necessarily  oriented  to  support  a  tape  struc¬ 
tured  rather  than  a  database  structured  information  system.  The  design 
and  documentation  for  operating  the  Army  personnel  systems  dates  back  to 
the  early  Seventies  when  the  current  SIDPERS  system  was  implemented. 
Everyone  recognizes  that  this  system  was  not  designed  for  (and  so  cannot 
readily  utilize)  current  state-of-the-art  procedures  for  managing  and 
sharing  personnel  data.  Under  the  constraints  inherent  in  the  present 
system,  it  is  also  clear  that  a  creditable  job  is  being  done  in  managing 
the  information  required  for  operating  the  Army's  extensive  and  complex 
personnel  functions.  No  one,  morever,  is  more  interested  in  upgrading 
present  system  technology  than  the  managers  of  the  Army  personnel  com¬ 
munity  themselves,  and  the  AIRMICS  interest  in  researching  DBMS  tech¬ 
nology  for  use  in  that  environment  should  be  a  welcome  involvement. 

In  reviewing  current  manpower  and  personnel  data  management 
procedures  for  AIRMICS,  the  Georgia  Tech  team  focused  primarily  on  the 
nature  of  the  several  interfaces  required  in  the  flow  of  Army  personnel 
data.  DBMS  technology  has  the  potential  for  improving  data  nanages»nt 
in  each  of  these  interface  situations.  In  the  course  of  this  review,  it 
was  evident  that  a  number  of  important  related  initiatives  are  already 
well  underway  within  the  Army  personnel  community.  These  include  the 
MILMAP  study,  the  standardization  conferences,  and  the  ERAD  study.  Each 
of  these  efforts  are  dealing  with  issues  and  problems  whose  resolution 
is  fundamental  to  any  attempt  to  incorporate  DBMS  technology  in  the 
management  of  Army  personnel  data. 

A  word  is  in  order  about  how  AIRMICS  might  build  on  each  of  these 
efforts.  In  the  case  of  the  MILMAP  study,  as  has  been  mentioned 
elsewhere  in  this  report,  the  objective  of  the  AMO's  (now  IRM's) 
involved  is  to  lay  down  a  Master  Autonation  Plan  for  future  systems 
revision  of  the  Army  personnel  information  system.  This  group  has 
approached  that  task  from  the  aspect  of  the  five  life  cycle  functions 
comprising  a  military  personnel  system's  management  goals.  In  carrying 
out  their  mission,  the  MILMAP  study  team  has  delineated  the  major  data 
flows  and  interfaces  required  in  operating  the  personnel  information 
system.  The  MILMAP  study  of  the  life  cycle  functions  can  provide 
AIRMICS  with  a  basis  for  dealing  with  technical  problems  such  as  the 
following: 


*  Single  source  data  entry 
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*  Edits  performed  at  the  point  of  data  entry 

*  Maintaining  data  stores  at  the  locations  where  they  are  used 

*  Determining  network  channels  for  the  appropriate 
exchange  and  distribution  of  personnel  data 

*  Determining  a  proper  role  for  minicomputers  and 
the  distribution  of  data  processing  functions 

*  Use  of  data  screens  for  information  input  and  update 

*  Reduction  of  hardcopy  information  listing 
and  reports 


The  MILPERCEN  sponsored  standardization  conferences  can  provide  AIRMICS 
with  help  in  the  data  documentation  process  that  is  absolutely  essential 
in  a  DBMS  operating  environment.  This  inter-agency  study  group  is 
currently  concentrating  on  reaffirming  the  data  element  standards  that 
have  not  always  been  observed  in  current  personnel  systems.  AIRMICS 
needs  to  consider  building  on  this  effort  and  extending  the  documenta¬ 
tion  effort  to  include  specifics  on  the  use  of  personnel  data  elements 
in  the  many  application  programs  in  service. 

The  MILPERCEN  sponsored  conferences  seemed  more  directly  concerned 
with  how  data  elements  should  be  defined  and  coded  rather  than  with  how 
they  are  currently  defined,  coded  and  used.  A  documentation  effort  of 
this  latter  sort  has  been  undertaken  by  the  SIDPERS-RC  group  at  RCPAC. 
This  group  has  already  made  headway  in  identifying  the  truly  comon  core 
of  data  elements  used  by  the  major  Army  personnel  databases  and  has  had 
the  foresight  to  maintain  this  information  on  DATAMANAGER,  which 
provides  the  type  of  extensive  data  element  information  required  by 
DBMS.  Presently  the  data  element  database  established  by  SIDPERS-RC 
contains  some  3,000  data  elements.  That  database  can  probably  be  made 
available  to  AIRMICS  in  a  form  that  they  can  use  for  further  study  and 
development. 

The  work  of  the  Standardization  conferences  is  still  in  progress, 
but  the  product  of  the  first  two  conferences  have  already  been  provided 
to  AIRMICS. 

The  Georgia  Tech  study  team  made  some  progress  in  acquiring  the 
record  layouts  of  the  personnel  data  files  in  use  at  MILPERCEN  and  at 
other  selected  Army  organizations.  These  files  included  both  master 
personnel  records  and  the  extract  and  work  tape  records  used  for 
exchanging  data  between  systems  and  for  updating  records  within  systems. 
The  data  elements  found  in  these  records  were  catalogued  and  placed 
among  the  materials  provided  in  the  appendices  found  in  Volume  II  of 
this  report. 

The  ERAD  study  group  has  been  engaged  in  a  work  effort  that  should 
assist  AIRMIC8  in  dealing  with  the  interface  between  MILPERCEN' s  OMF  and 
EMF .  This  group  has  identified  the  universe  of  Army  personnel  data 


FINAL  REPORT  June  30,  1981 


Army  Personnel  Data  Sharing  Project  (FINAL  REPORT) 


Page  20 


elements  which  personnel  managers  claim  they  need  to  have  automated  in 
order  to  carry  out  their  functions.  One  objective  of  the  ERAD  study  is 
to  create  a  single  personnel  file  for  both  officers  and  enlisted  person¬ 
nel  (to  be  known  as  the  Individual  Record  Brief  or  IRB) .  In  this  con¬ 
nection,  it  is  worth  noting  that  RCPAC's  personnel  data  already  exists 
in  this  combined  form.  This  approach  to  interfacing  the  OMF  and  EMF  has 
obvious  implication  for  any  AIRMICS  effort  to  design  DBMS  software  for 
the  active  army  personnel  system.  The  work  product  of  the  ERAD  study 
group  is  referenced  in  the  appendices  of  this  report  and  a  listing  of 
their  universe  of  personnel  data  elements  forms  one  of  the  appendices. 

In  reviewing  the  current  status  of  personnel  data  management  within 
the  Army  personnel  consnunity,  then,  the  Georgia  Tech  study  team  has 
found  much  evidence  that  there  is  a  well-developed  receptiveness  for  the 
type  of  DBMS  research  which  AIRMICS  wishes  to  undertake.  Enough  has 
been  and  is  being  done  within  the  Army  personnel  community  to  insure 
that  Che  AIRMICS  effort  will  provide  research  outcomes  that  will  have 
ne.'r;  term  benefits  for  upgrading  the  current  personnel  information 
management  systems.  As  pointed  out  previously,  concern  for  Mobilisation 
s«d  Wartime  operating  conditions  only  makes  this  type  of  research  even 
more  desirable.  In  engaging  in  research  on  DBMS  applications  within  the 
A-ry  personnel  community,  AIRMICS  will  be  dealing  with  a  number  of 
si:...?  .‘.rent  interface  problems,  all  of  which  should  prove  amenable  to 
resolution  by  DBMS  technology.  This  section  will  conclude  with  a  brief 
overview  of  these  interfaces. 

1 .  Interface  among  the  Active  Army,  the  National  Guard  and  the 
Reserve  Army.  This  interface  is  characterized  by  the  need  to  have  a 
smooth  transfer  of  gain  and  loss  transactions  among  databases  which  need 
to  maintain  their  separate  identity  and  control.  There  are,  however, 
administrative  and  financial  reasons  for  insuring  that  these  databases 
are  in  a  position  not  only  to  register  and  accomplish  individual  record 
gains  and  losses,  but  at  the  same  time  to  permit  mutually  beneficial 
inquiries.  Because  of  the  different  information  needs  of  the  separate 
Army  organizations,  the  data  element  content  will  never  be  entirely 
uniform.  Attention  should  be  paid,  however,  to  insuring  that  common 
elements  observe  approved  standards  of  definition  and  structure.  The 
respective  organizations  also  need  to  be  kept  current  of  the  unique 
elements  maintained  in  the  other  databases  and  have  the  technology  to 
access  that  information  in  accordance  with  approved  security  and  access 
procedures. 

2.  The  interface  between  MILPERCKN  master  files  and  SIDPERS 
Installation  files.  This  is  the  main  pipeline  interface  by  which 
OMF/EMF  records  are  updated.  Transactions  across  this  interface  are 
critical  to  the  validity  of  the  MILPERCEN  master  personnel  database. 
This  interface  also  introduces  the  most  challenging  potential  for  design 
reorganization  under  DBMS.  DBMS  offers  the  potential  for  consolidating 
the  MILPERCEN  and  SIDPERS  database  into  an  integrated,  distributed  data 
processing  system.  From  the  observation  of  the  Georgia  Tech  team,  this 
remains  a  long-term,  remote  concept  in  the  thinking  of  most  current  Army 
personnel  data  managers.  For  that  reason,  and  because  of  its  inherent 
complexities,  it  will  be  the  interface  requiring  the  most  intensive 
research  activity  on  the  part  of  AIRMICS. 
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3.  The  MILPERCEN  interface  with  the  USAFAC  JUMPS  file.  Both 
MILPERCEN  and  USAFAC  maintain  their  own  separate  pipelines  to  field 
level  data.  At  the  Base/Installation  level,  the  MILPERCEN  database  is 
serviced  by  the  MILPO,  while  the  FAO  serves  as  the  USAFAC  point  of 
contact.  At  present,  the  top  of  the  system  exchange  of  data  between 
MILPERCEN  and  USAFAC  provides  each  organization  with  personnel  informa¬ 
tion  useful  for  validating  and  purifying  their  respective  files.  Using 
DBMS  concepts  to  establish  a  common  Army  personnel  database  would  effec¬ 
tively  eliminate  this  interface.  Past  attempts  to  consolidate  pay  and 
personnel  data  have  been  ineffective,  and  the  issue  remains  a  sensitive 
political  one  for  both  organizations.  It  seems  safe  to  conclude  that 
the  difficulties  here  will  never  be  entirely  resolved  until  the  Army  has 
a  personnel  database  accepted  as  reliable  by  both  organizations.  Deal¬ 
ing  successfully  with  this  interface  should  be  considered  an  important, 
but  long  term  outcome  of  the  AIRMICS  research  effort. 

4.  Database  extracts  provided  by  MILPERCEN  to  other  Army  or¬ 
ganizations.  USAMSSA  and  other  major  Army  commands  routinely  receive 
OMF/EMF  extracts  and  other  reports  based  on  these  databases.  In  many 
instances,  this  interface  requires  the  modification  of  raw  OMF/EMF 
information  into  formats  and  structures  required  for  the  data  to  be 
useful  to  the  receiving  organization.  This  introduces  a  layer  of  work 
tapes  into  the  MILPERCEN  data  processing  environment  which  raises  the 
question  of  unnecessary  data  redundancy.  This  problem  is  currently 
under  study  as  part  of  the  mission  of  the  Data  Standards  Conferences. 
DBMS  can  be  expected  to  have  data  extracts  and  reporting  capabilities 
that  should  greatly  reduce  the  data  duplication  introduced  into  a  system 
by  the  use  of  work  tapes.  This  should  be  one  of  the  near  term  outcomes 
of  the  research  effort  envisioned  by  AIRMICS. 

5 .  The  interface  required  to  answer  special  and  routine  queries  to 
the  OMF/EMF  databases.  Activities  of  this  type  are  currently  worked 
against  the  System  2000  database  and  the  compressed  OMF/EMF  tapes 
processed  with  ODIS.  Since  DBMS  technology  is  specifically  tailored  to 
improvements  in  this  type  of  data  processing  service,  the  AIRMICS 
research  effort  can  be  expected  to  produce  significant  near-term 
improvements  in  this  type  of  interface.  This  is  also  the  interface  that 
will  have  the  most  visibility  with  end-users  and  should  vastly  improve 
field  level  support  for  the  entire  system.  Improvement  in  this  area  can 
also  be  expected  to  produce  spin-off  effects  on  MILPERCEN's  capability 
for  keeping  data  validity  at  a  high  level.  As  end-users  are  able  to 
interact  with  data  as  it  actually  exists  in  the  database,  they  become  a 
new  and  effective  data  checking  resource. 
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SECTION  IV. 

ISSUES  BKLRVAWT  T£  X&E  INTERFACING  QL  ARMY  AUTOMATED 
PERSONNEL  DATA  SYSTEMS 


Previous  sections  of  this  report  have  reviewed  the  current  status 
of  Army  automated  personnel  data  systems,  and  have  sketched  an  outline 
of  what  an  effective,  integrated  system  might  look  like  in  the  future. 
The  present  task,  then,  is  to  consider  the  prospects  for  making  a  smooth 
transition  to  a  system  able  to  meet  the  needs  of  Army  mobilization  and 
to  take  full  advantage  of  current  information  systems  technology.  These 
prospects  may  be  examined  in  terms  of  five  major  issues.  These  issues 
are  identified  and  discussed  under  the  headings  presented  in  the  remain¬ 
der  of  this  section. 

1.  THE  ISSUE  OF  OFF-LINE  PERIODIC  DATA  TRANSFERS 

The  work  statement  that  motivated  this  study  suggested  that  serious 
problems  existed  as  the  result  of  the  fact  that  present  system  inter¬ 
faces  were  off-line  and  periodic  rather  than  on-line  and  interactive. 
The  following  sentences  may  be  directly  quoted: 

"The  data  transfers  [in  particular,  between  MILPERCEN,  JUMPS, 
and  SIDPERS  systems]  are  accomplished  on  a  periodic  basis  via 
a  magnetic  tape  interchange  between  system  proponents.  This 
method  for  maintaining  data  integrity  between  systems  is 
inefficient  and  results  in  costly  manual  processing  to 
resolve  inter system  discrepancies.  There  are  no  conver¬ 
sational,  interactive  processes  involved  in  the  efforts  to 
use  data  base  information  from  differing  Army  agencies." 

This  statement  was  no  doubt  meant  to  be  nothing  more  than  a 
tentative  and  exploratory  description  of  the  problem.  However,  one 
should  note  that  the  statement  rather  clearly  characterizes  not  only  the 
problem  but  also  the  expected  solution;  for,  according  to  this 
statement,  the  problem  is  that  off-line  processing  results  in  "costly 
manual  processing  to  resolve  inter-system  discrepancies,"  and  the  remedy 
to  "costly  manual  processing"  is  the  development  of  interfaces  with 
interactive  capabilities. 

The  work  statement  also  suggests,  as  a  solution  to  the  above- 
identified  "problem,"  the  creation  of: 


”...  a  common  data  bank,  or  data  utility. ..The  data  bank 
would  be  established  by  consolidating  the  personnel  and 
financial  data  bases  of  MILPERCEN  and  USAFAC  into  an 
automated  system  providing  a  single,  unimpeachable  source  of 
data  for  the  personnel  and  financial  activities. 

Although  the  data  bank  concept  is  currently  under 
investigation  only  by  MILPERCEN  and  USAFAC,  it  is  generally 
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accepted  that  the  concept  could  be  extended  to  serve  the 
other  members  of  the  personnel  community.  The  data  bank 
would  provide  a  data  sharing  utility  including  the  interfaces 
necessary  to  satisfy  all  mutual  data  accession  requirements 
of  members  of  the  personnel  conmunity  and  USAFAC.  The  data 
bank  would  provide  a  data  sharing  utility  including  the 
interfaces  necessary  to  satisfy  all  mutual  data  accession 
requirements  of  members  of  the  personnel  community  and 
USAFAC.  The  data  bank  would  also  eliminate  the  need  for  off¬ 
line  transfer  of  data  bases,  or  portions  thereof,  between 
high-level  Army  managers  for  the  purpose  of  data  management 
and  strength  reconciliation." 

Before  proceeding  further  in  a  discussion  of  interface  issues,  it 
is  important  to  try  to  estimate  the  extent  to  which  the  preceding 
statements  are  in  fact  accurate  characterizations  of  the  current 
situation.  In  this  regard,  one  might  make  the  following  observations: 

*  There  is  no  real  indication  that  reconciliation  of 
data  between  the  JUMPS  and  MILPERCKN  (OMF/EMF)  results  in 
costly  manual  processing.  At  present,  neither  USAFAC  nor 
MILPERCEN  allocates  any  substantial  portion  of  its  resources 
to  the  effort  of  manually  reconciling  specific  mismatches  or 
inconsistencies  between  the  two  systems.  To  the  contrary, 
such  inconsistencies  seem  in  general  to  be  of  little  concern 
to  system  managers,  who  know  that  most  mismatches  are  tem¬ 
porary,  resulting  merely  from  different  processing  cycles  at 
USAFAC  and  MILPERCEN.  Realignment  of  the  processing  cycles 
at  USAFAC  and  MILPERCEN  would  therefore  resolve  a  large  per¬ 
centage  of  the  data  discrepancies  (and  there  has  been  some 
effort  to  study  the  possibility  of  making  such  a 
realignment);  however,  there  obviously  has  been  no  sense  of 
urgency  on  the  matter,  for  the  apparently  good  reason  that 
the  "problem"  is  not  a  very  serious  problem  at  all.  That  is 
to  say,  it  does  no  real  harm,  and  therefore  is  in  no  way  seen 
by  system  managers  to  represent  an  alarming  state  of  affairs. 

*  In  contrast  to  the  interface  with  JUMPS,  the  interface 
with  SIDPERS  seems  to  require  somewhat  more  elaborate  manual 
processing  efforts  in  order  to  resolve  individual 
discrepancies.  However,  those  discrepancies  exist  less  on 
account  of  the  lack  of  an  interactive  interface  then  on  ac¬ 
count  of  a  lack  of  controls  on  the  information  processed.  In 
other  works,  the  problem  is  not  an  interface  problem  so  much 
as  it  is  a  data  capture  problem.  Data  coming  from  SIDPERS  to 
MILPERCEN  is  overlaid  on  the  existing  OMF/EMF  file  without 
sufficient  checks  to  make  sure  the  data  is  accurate. 
Therefore,  every  time  a  MILPO  makes  an  attempt  to  update  an 
item  in  a  master  record,  there  is  the  serious  possibility 
that  brand  new  errors  will  be  introduced  into  the  file  —  for 
there  is  no  procedure  to  prevent  their  introduction  into  the 
OMF/EMF.  (It  must  also  be  observed  here  that  the  system  in 
no  way  checks  the  performance  of  the  SIDPERS  clerks. ..no 
clock  starts  running  when  a  MILPERCEN  action  calls  for  an 
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action  at  a  given  base...  the  diligence  or  lack  thereof  of  a 
given  clerk  goes  unchecked.) 

*  Interfaces  between  OMF/EMF  and  systems  other  than  SID- 
PERS  and  JUMPS  do  not  appear  to  require  interactive  proces¬ 
sing  capabilities.  At  DCSPERS,  for  example,  there  is  a 
mission-directed  need  to  develop  an  independent  data  base 
quite  different  from  the  data  base  maintained  in  the  OMF/EMF. 

In  order  to  make  strength  predictions,  DCSPERS  requires  data 
aggregated  and  classified  in  a  longitudinal  data  base 
maintained  for  seven  years.  DCSPERS  therefore  is  interested 
in  aggregates  rather  than  individuals,  in  trends  rather  then 
in  the  current  situation.  Thus,  "off-line,  periodic  data 
transfer"  from  the  OMF/EMF  is  quite  adequate  to  DCSPERS 
purposes . 

What  emerges  from  these  facts  is  the  conclusion  that  the  document 
which  motivated  the  project  misstated  the  nature  of  the  problem,  and 
pointed  toward  a  solution  which  is  not  appropriate.  There  is  no  urgent 
problem  with  regard  to  the  management  of  existing  interfaces;  to  the 
contrary,  the  system  managers  both  at  MILPERCEN  and  elsewhere  appear  to 
be  doing  an  exemplary  job  in  regard  to  the  interfacing  of  existing 
systems,  given  the  history  and  nature  and  complexity  of  those  systems 
and  the  obsolescence  of  the  hardware  and  software  available  to  support 
them.  The  problem,  therefore,  is  not  with  the  system  INTERFACES;  the 
problem  is  with  the  SYSTEMS  THEMSELVES  —  systems  which  are  now  out-of- 
date  and  entirely  unable  to  take  advantage  of  current  state-of-the-art 
information  systems  technology. 

2.  THE  ISSUE  OF  MANAGEMENT  CONSENSUS 

Given  the  complexity  and  size  of  the  various  automated  systems 
related  to  Army  manpower  management,  it  is  not  surprising  that  a  large 
number  of  separate  but  overlapping  studies  have  been  initiated  within 
the  last  several  years.  For  example,  a  number  of  joint  MILPERCEN-USAFAC 
studies  were  brought  into  being  as  a  result  of  a  memorandum  of  under- 
jtanding  written  by  General  Crosby.  In  addition,  there  has  been  the 
COPPER  report,  the  MAPS  report,  the  ERAD  study,  etc.,  plus  on-going 
internal  studies  by  groups  such  as  the  Research  and  Analysis  Branch  of 
the  Data  Base  Management  Divison  of  FERSINSD. 

In  order  for  outsiders  such  as  the  present  researchers  to  take  a 
realistic  approach  to  the  formulation  of  recommendations  for  choosing 
any  particular  direction  for  further  study  or  action,  it  is  necessary 
that  they  pause  to  reflect  on  the  history  and  status  of  these  studies. 

Of  the  various  projects  mentioned  in  the  General  Crosby  memorandum, 
only  two  remain  in  any  kind  of  active  status,  and  of  those  two  only  one 
is  proceeding  forcefully:  the  data  element  standardization  project.  As 
for  the  other  reports:  the  COPPER  report  has  been  rejected;  the  ERAD 
study  remains  controversial;  the  MAPS  program  is  not  at  all  assured  of 
management  acceptance  or  completion. 

The  existence  of  all  these  study  efforts  leads  quickly  to  the 
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conclusion  that  managers  are  doing  their  utmost  to  exercise  their 
responsibilities  for  administering  their  systems  in  a  way  that  maximizes 
opportunities  for  effective  interface  with  other  systems;  but  the 
failure  or  slow  progress  of  most  of  those  same  efforts  leads  to  the  con- 
lusion  that  efforts  such  as  these  have  been  founded  in  a  global  perspec¬ 
tive  that  makes  real  progress  impossible  or  at  least  difficult.  Whereas 
consolidation  of  OMF/EMF  (strictly  within  the  purview  of  MILPERCEN) 
seems  to  be  proceeding  rapidly,  one  sees  that,  in  contrast,  those 
reports  dealing  with  interagency  cooperation  (e.g.,  the  COPPER  report, 
the  studies  outlined  in  the  Crosby  memorandum)  have  been  rejected  or 
abandoned,  and  the  MAPS  project  seems  far  from  implementation. 

It  would  seem  that  no  one  group  has  management  (as  opposed  to 
staff)  responsibility  for  the  overall  task  of  interface  management.  The 
interfacing  between  discrete  systems  has  historically  been  treated  as  a 
problem  of  liaison  and  coordination  rather  than  a  problem  of  design  and 
management.  Therefore,  the  interfacing  question  has  been  given  to 
staff/liaison  groups  such  as  the  AMO's,  rather  than  specifically  to  a 
design/management  group  such  as  DBMD  of  PERSINSD. 

The  high  rate  of  failure  of  interfacing  studies  would  seem  to  sug¬ 
gest  that  no  substantial  progress  is  possible  regarding  the  development 
of  acate-of-the-art  Army  personnel  systems  until  there  is  developed  a 
management  consensus  within  the  personnel  community,  with  interface 
defined  not  as  a  connection  between  independent  systems,  but  rather  as 
one  between  inter-dependent  subsystems  of  a  single  system,  with  a  single 
management . 

3.  THE  ISSUE  OF  DATA  PROPOHENCY 

Included  in  the  project  work  statement  was  the  clear  suggestion 
that  one  of  the  important  obstacles  to  effective  interfacing  has  been  an 
insufficient  degree  of  formalization  with  respect  to  the  designation  of 
data  proponency.  Indeed,  one  of  the  joint  USAFAC-MILPERCEN  study  teams 
was  tasked  to  propose  a  resolution  for  data  proponency  issues  that  exist 
between  the  two  agencies.  Of  course,  that  study  was  one  of  the  ones 
which  has  been  abandoned,  but  at  least  one  other  similar  effort  (within 
MILPERCEN  itself)  has  been  initiated. 

Two  major  difficulties  arose  when  the  present  researchers  attempted 
to  inquire  into  the  nature  of  the  data  proponency  problem.  The  first  is 
that  there  are  different,  sometimes  ambiguous,  and  sometimes  conflicting 
uses  of  the  phrase  "data  proponency."  That  is  to  say,  a  "proponent 
agency"  is  sometimes  thought  to  be  the  one  responsible  for  legal 
definition  of  a  term  or  "data  element";  sometimes  as  the  one  responsible 
for  the  standard  formatting  of  a  data  element;  sometimes  as  the  one  most 
interested  in  the  data;  sometimes  as  the  one  which  first  collects  the 
data;  sometimes  as  the  one  most  likely  to  have  the  most  accurate  data. 
Thus,  the  data  proponency  issue  is  easily  decided  only  in  those 
relatively  few  cases  in  which  a  single  agency's  relation  to  a  data 
element  happens  to  meet  ALL  the  above  criteria;  in  fact,  in  all  other 
cases,  the  issue  can  by  definition  never  in  fact  be  resolved  entirely, 
unless  an  arbitrary  decision  is  made  to  choose  just  one  of  the  possible 
perspectives  on  data  proponency  as  the  "correct"  one;  this,  however,  is 
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not  a  realistic  approach,  for  each  of  the  perspectives  mentioned  has  at 
least  some  legitimate  claim  to  be  the  most  important  one. 

A  second  difficulty  that  confronts  analysts  attempting  to  deal  with 
the  notion  of  data  proponency  is  the  fact  that,  perhaps  contrary  to 
one's  expectation,  agencies  are  not  necessarily  anxious  to  accept 
designation  as  a  proponent  agency.  One  senior  officer  said:  "We  would 
love  to  have  [a  particular  agency  other  than  his  ownl  accept  proponency 
(for  data  elements  x,y,z],  because  that's  the  business  they're  in; 
that's  their  responsibility.  But  they  refuse  to  accept  it;  and  it's 
probably  just  as  well  —  because  we  don't  trust  their  data."  (Note  that 
he  was  obviously  thinking  of  data  proponency  in  at  least  two  entirely 
different  senses:  first,  in  the  sense  of  DATA  ELEMENT  proponency, 
second  in  the  sense  of  DATA  proponency  -  from  the  particular  perspective 
of  data  ACCURACY.) 

The  confusion  in  which  proponency  notions  are  enmeshed  suggests 
that  data  proponency  is  an  unlikely  key  for  unlocking  the  solution  of 
system  interface  problems.  Ill-defined  proponencies  are  not  the  CAUSE 
of  the  interface  problem;  to  the  contrary,  proponency  becomes  an  issue 
only  as  a  CONSEQUENCE  of  that  problem.  If  there  existed  within  the  Army 
a  management  consensus  such  as  the  one  alluded  to  above,  the  Army 
automated  personnel  systems  could  be  administered  as  a  single  system, 
and  proponency  issues  would  be  resolved  pragmatically  rather  than 
theoretically  (and,  it  might  be  added,  unworkably). 

4.  THE  ISSUE  OF  DATA  ELEMENT  STANDARDIZATION 

Data  element  standardization  is  one  of  the  few  problems  which  have 
continued  to  receive  sustained  attention  at  the  multiagency  level. 
Regular  meetings  have  been  held  under  the  auspices  of  MILPERCEN  (and  in 
particular  the  auspices  of  the  Data  Base  Management  Division  of  PER- 
SINSD);  these  meetings  appear  to  have  resulted  in  an  impressive  degree 
of  progress.  However,  it  needs  to  be  noted  that,  like  the  proponency 
issue,  the  standardization  issue  contains  more  ambiguities  than  is 
sometimes  realized.  The  basic  reason  f st  »uch  ambiguities  is  probably  a 
result  of  the  fact  that  standardizati.r’e  is  always  purchased  at  a  price, 
and  when  the  price  is  high  enough,  the  standardization  effort  is  either 
abandoned  or,  more  likely,  trivialized.  Granted,  it  is  difficult  to 
find  anyone  willing  to  say  a  bad  word  about  standardization  (or  mother¬ 
hood);  but  it  is  also  difficult  to  find  anyone  who  is  genuinely 
optimistic  that  global  standardization  is  a  goal  that  can  actually  be 
achieved. 

For  example,  one  system  manager  who  was  interviewed  said:  "I've 
been  around  here  twenty  years,  and  they've  been  talking  about  standar¬ 
dization  all  that  time.  But  what  good  has  it  done?  Where's  the  stan¬ 
dardization?  They'll  be  talking  about  standardization  twenty  years 
after  I'm  gone." 

Somewhere  between  the  pessimism  of  this  last  statement  and  the 
optimism  it  refutes  is  a  realistic  attitude  which  regards  standar¬ 
dization  not  as  an  end  in  itself  but  merely  as  an  instrument  for 
achieving  certain  objectives.  When  such  an  attitude  is  adopted,  and 
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when  the  objectives  are  themselves  realistic  and  also  relatively  well- 
defined,  then  and  only  then  does  a  standardization  effort  have  a  chance 
of  being  both  successful  and  genuinely  meaningful.  This  being  the  case, 
it  is  crucial  to  determine  a  strategy  for  relating  standardization 
efforts  to  specific  organizational  needs. 

One  way  of  making  such  a  determination  is  to  look  at  the  standar¬ 
dization  problem  in  conjunction  with  the  documentation  problem.  When 
this  is  done,  many  of  the  "problems"  of  nonstandardization  turn  out  not 
really  to  be  problems  at  all.  That  is  to  say,  format  differences 
between  a  single  data  element  contained  in  two  different  data  bases  may 
in  fact  be  different  for  some  good  reason;  and  if  that  is  so,  then  the 
fact  of  nonstandardization  will  be  good  rather  than  bad  —  providing  of 
course  the  differences  are  well-documented  and  known  to  users  of  both 
systems. 

However,  that  proviso  is  crucial,  and  the  Army  personnel  community 
should  carefully  reexamine  the  state  in  which  the  documentation  of  it6 
automated  systems  currently  exists.  Documentation  of  data  flows,  record 
layouts,  data  formats,  common  data  elements,  system  protocols,  etc.,  are 
not  activities  which  can  be  casually  assigned  to  an  internal  ad  hoc 
study  group  or  to  outside  consultants  on  a  short-term  project.  They 
comprise  a  major  management  responsibility  that  must  be  implemented  and 
managed  on  a  massive  and  on-going  basis. 

The  lack  of  careful  documentation  within  the  Army  personnel  com¬ 
munity  is  a  problem  which  needs  imnediate  and  aggressive  management 
attention.  At  various  times  during  the  course  of  this  project  the 
researchers  found  themselves  unable  to  obtain  information  that  ought  to 
be  routinely  available  to  anyone  asked  to  analyze  the  effectiveness  of 
system  interfaces.  This  is  of  course  not  to  say  that  there  exists  no 
system  documentation  whatsoever;  it  is  merely  to  say  that  existing 
documentation  is  inadequate,  not  readily  available,  and  not  forcefully 
managed.  Serious  thought  therefore  should  be  given  to  the  possibility 
of  creating  at  a  high  level  within  MILPERCEN  an  office  of  systems 
documentation,  which  would  develop  and  maintain  multisystem  documenta¬ 
tion  efforts. 

5.  THE  ISSUE  OF  OPERATIONAL  RESEARCH 

Like  the  documentation  effort  discussed  above,  the  operational 
research  effort  needs  to  be  on-going,  comprehensive,  and  managed  as  a 
major  management  activity.  At  PERSINSD  within  MILPERCEN,  this  effort  is 
conducted  primarily  by  the  Data  Research  and  Analysis  Branch  of  the  Data 
Base  Management  Division.  At  USAFAC,  a  similar  activity  is  conducted. 
Both  activities  focus  serious  and  useful  attention  to  system  problems 
related  to  the  MILPERCEN-USAFAC  interface  and  other  interfaces,  as  well 
as  to  internal  systemic  problems  within  the  individual  organizations. 
Beyond  such  fine  efforts,  however,  it  would  be  very  worthwhile  to  have 
statistical  studies  done  which  are  not  now  available. 

Specifically,  studies  would  be  extremely  useful  if  they  documented 
the  number  and  kind  of  accesses  made  to  the  various  data  bases.  An  ap¬ 
propriate  data  base  design  can  not  be  created  until  there  is  available  a 
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vast  amount  of  information  on  hov  the  data  base  is  actually  used  or  to 
be  used  by  actual  users.  Information  of  this  kind  can  be  obtained  only 
through  a  long-term  operational  interest  and  effort  to  maintain  relevant 
system  usage  statistics.  At  the  present,  there  is  no  way  of  knowing, 
for  example,  how  many  requests  were  made  last  month  by  users  wanting  to 
know  something  about  medals  and  awards;  yet  such  information  is 
essential  to  designers  seeking  to  develop  an  efficient  and  effective 
automated  system  for  personnel  management.  If  there  is  frequent  and 
extensive  use  of  data  on  medals  and  awards,  then  one  kind  of  data  struc¬ 
ture  is  appropriate  for  the  data  base  which  holds  that  information;  on 
the  other  hand,  if  there  is  virtually  no  extensive  or  critical  use  made 
of  such  information,  then  a  different  kind  of  data  structure  will  be 
appropriate.  When  detailed  statistics  of  this  kind  are  not  available  on 
all  of  the  elements  in  the  various  data  bases,  a  truly  rational  data 
base  design  process  is  not  possible. 

One  approach  the  Army  personnel  comnunity  might  consider  to  remedy 
this  problem  is  to  incorporate  into  the  programs  of  each  automated 
system  a  set  of  counters  which  will  produce  usage  statistics  for  all 
data  elements.  Adoption  of  such  an  approach  would  have  an  ismtediate, 
short-term  cost  in  programming  effort  and  system  run-times,  but  would 
yield  high  long-term  benefits,  by  providing  information  that  systems 
designers  simply  can  not  afford  to  be  without. 


i 

i 


i 


Army  Personnel  Data  Sharing  Project  (FINAL  REPORT) 


Page  29 


SUMMARY  OF  ISSPES 

The  recomnendations  made  in  Section  VI  of  this  report  are  responses 
to  the  issues  raised  above  as  restated  in  the  following  five  questions. 

(1)  Is  the  development  of  automated  system  interfaces 
practicable  or  desirable  prior  to  the  redevelopment  of  the 
primary  systems  themselves  using  modern,  state-of-the-art 
information  systems  technology? 

(2)  In  what  ways  can  systems  interfacing  be  accomplished 
by  technical  means  prior  to  the  resolution  of  major  questions 
related  to  overall  management  direction  within  the  total  Army 
personnel  community? 

(3)  Can  the  redevelopment  of  automated  information 
systems  within  the  Army  personnel  community  facilitate 
solutions  to  the  problem  of  clarifying  organizational  boun¬ 
daries  and  responsibilities  relative  to  Army  personnel  data? 

(4)  Can  the  data  element  standardization  effort  hope  to 
be  successful  if  standardization  activities  are  not  trans¬ 
ferred  from  an  ad  hoc  basis  to  one  which  is  permanently 
constituted  and  able  to  assume  major,  on-going  management 
responsibility  for  documentation  (and  documentation 
maintenance)  of  all  automated  Army  personnel  information 
systems  and  their  interface  requirements? 

(5)  To  what  extent  will  it  be  possible  to  effect  the 
administrative  changes  necessary  to  accomplish  the  massive 
information  collection  functions  which  need  to  be  conducted 
prior  to  the  design  specification  for  state-of-the-art 
hardware/ software  required  for  current  and  future  needs  of 
the  manpower  information  systems  needs  of  the  modern  United 
States  Army? 

What  will  emerge  in  the  following  pages  of  this  report  is  that  the 
degree  to  which  the  Army  will  be  able  to  answer  those  five  questions 
will  be  a  function  of  whether  it  is  first  able  to  provide  a  mechanism 
for  facilitating  the  development  of  a  comprehensive  framework  for  plan¬ 
ning  the  long-range  future  of  information-technology  ulitization  on 
behalf  of  Army  personnel  management. 
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SECTION  V. 

WORKSHOP  FINDINGS 


With  Sections  I.  through  IV.  of  this  report  serving  as  a  back¬ 
ground  document,  the  participants  in  the  Army  Human  Resources  Management 
Information  Systems  Workshop  held  in  Atlanta  on  October  6-8,  1980,  were 
able  to  review  the  salient  features  of  typical  Army  personnel 
organizations  and  to  arrive  at  a  broad  consensus  concerning  the  major 
issues,  problems,  and  opportunities  for  improvement  within  the  Army's 
personnel  information  systems.  Though  there  were  some  minor 
disagreements  among  the  Workshop  participants,  those  disagreements  were 
far  less  important  than  the  clear  consensus  which  was  reached  on  the 
principal  topics  covered.  Those  topics  were  "System  Objectives";  "Major 
Problems  in  the  Personnel  Information  Systems  Environment";  "Proposed 
System  Solution";  "Impediments  to  System  Development";  and  "A  Plan  for 
Action".  The  consensus  achieved  on  the  identified  topics  is  reported  in 
the  following  pages. 

Some  members  of  the  Workshop  concluded  that  their  initial  thoughts 
on  the  problem  of  defining  system  objectives  had  been  rather  naive,  and 
that,  though  the  topic  of  system  objectives  had  at  first  appeared  to  be 
relatively  straightforward,  the  actual  analysis  proved  to  be  much  more 
difficult.  The  systems  objectives  of  the  Army's  Human  Resouces  Informa¬ 
tion  Systems  turned  out  to  be  elusive,  and  not  quickly  agreed  upon. 

The  primary  reason  for  this  difficulty  was  that,  unlike  virtually 
all  private  sector  organizations,  the  Army  is  required  to  design  a 
system  that  will  provide  optimal  service  in  each  of  two  radically 
different  circumstances:  peacetime  and  wartime.  This  is  tantsaiont  to 
being  required  to  design  two  separate  systems,  with  two  separate  and  in 
many  ways  quite  different  sets  of  objectives.  The  transition  from 
peacetime  to  wartime  must  be  swift  and  secure.  The  transition  from 
wartime  to  peacetime  must  preserve  and  maintain  data. 

The  Workshop  members  agreed  that  dichotomous  objectives  were 
involved.  Basically,  the  system  would  be  asked  to  maintain  an 
operational  readiness  to  fight  a  general  war  (which  is,  after  all,  the 
mission  of  the  Army),  and  yet,  at  the  very  same  time,  serve  the  day-to¬ 
day  vital  needs  of  the  Army  in  peacetime. 

It  was  observed  that  there  has  not  been  an  all-out  mobilization 
since  1945,  and  that  most  of  the  years  since  then  have  in  fact  been 
years  of  relative  peace;  thus,  it  is  necessary  to  be  cautious  in  using 
an  otherwise  valuable  slogan  such  as:  "design  for  war;  modify  for 
peace."  Modification  of  a  system  works  best  (if  at  all)  when  the 
modifications  required  are  relatively  minor.  On  the  other  hand,  if  the 
modifications  are  numerous  and/or  vast,  the  modified  system  will  tend  to 
prove  unsatisfactory  or  unworkable.  There  is  the  real  danger  that  a 
system  designed  to  achieve  two  different  and  somewhat  incompatible  sets 
of  goals  will  achieve  neither. 
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As  a  result,  the  Workshop  participants  felt  that  personnel  resource 
management  should  provide  accurate  and  timely  information  in  the  modes 
appropriate  to  each  of  tvo  different  conditions.  First  of  all,  the 
primary  mission  is  to  achieve  the  maximum  personnel  readiness  for  any 
military  contingency;  this  is  the  Army's  number  one,  f irst-and-foremost 
objective.  Second,  the  Army  must  maintain  an  effective  resource 
management  system  for  time  of  peace;  that  is,  it  must  be  able,  in  an 
efficient  and  effective  way,  to  go  about  the  routine  but  essential 
business  of  personnel  management  of  the  sort  conducted  regularly  by  any 
large  enterprise,  private  sector  as  well  as  public. 

For  personnel  readiness  for  any  contingency,  which  must  remain  the 
first  and  ultimately  most  important  component  of  a  Human  Resources 
Management  Information  System  for  the  Army,  information  must  be 
available  and  responsive  to  the  needs  of  managers.  Furthermore,  this 
vital  information  should  be  equally  available  to  all  decision  makers 
with  the  need-to-know,  regardless  of  their  organizational  affiliation: 
that  is  to  say,  the  system  should  be  designed  to  serve  the  needs  of  the 
entire  fighting  Army,  not  just  a  segment  of  it. 

Another  point  is  that  the  data  base  that  contains  this  information 
should  be  designed  so  that  it  can  be  expanded  rapidly  in  size.  The 
Workshop  participants  agreed  that  the  Army  needs  to  be  talking  about  a 
wide  range  of  possible  military  contingencies,  from  "brush  fires"  to 
general  war  situations,  and  needs  to  be  thinking  about  a  system  design 
that  will  be  iamediately  responsive  to  increases  of  varying  Bizes  depen¬ 
ding  on  mobilization  requirements. 

The  second  major  objective  of  the  information  system  is  easier  to 
characterize,  for  it  more  closely  resembles  the  kind  of  human  resource 
management  information  system  found  in  the  civilian  world.  For  the  sake 
of  consistency  (and  to  provide  a  contrast  with  the  "lean  and  mean" 
system  required  for  war  time),  the  Workshop  participants  also  insisted 
that  the  system  needed  to  be  "fat  and  happy"  (i.e.,  responsive  to 
individual  career  aspirations,  geographical  preferences,  and  all  the 
myriad  subtleties  of  human  resource  development).  The  second  objective 
may  be  enumerated  as  follows: 

*  Maintain  longitudinal  data 

*  Maintain  historical  data 

-  Assignments 

-  Education  (Civilian  and  Military) 

-  Awards;  etc. 

*  Maintain  demographic  data 

*  Maintain  planning  data  for  forecasting 

*  Evaluate  and  maintain  appropriate  forecasting 
models 

*  Provide  analysis  and  reporting  tools 

which  are  responsive  to  ad  hoc  requirements. 

In  contrast  to  the  requirements  associated  with  the  first  objec¬ 
tive,  it  can  be  seen  that  the  human  resource  management  information 
system  needed  to  meet  the  second  objective  is  more  of  a  traditional 
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human  resource  system  in  that  it  maintains  historical  data,  requiring 
traces  of  previous  assignments,  education,  and  all  of  the  other  things 
needed  to  run  the  day-to-day  operation  in  the  face  of  myriad  privacy, 
individual  rights,  and  EEO  requirements.  The  required  system  has  two 
major  goals,  rather  than  one.  Yet  the  most  significant  aspect  of  this 
dichotomy  is  not  simply  that  they  are  two  different  goals,  but  that 
these  two  goals  are  vastly  different  from  one  another,  and  perhaps  in 
some  ways  not  entirely  compatible  in  one  system  intended  to  optimize 
under  either  or  both  conditions. 

Major  Problems  in  the  Human  Information  Systems  Environment 

The  second  topic  upon  which  a  broad  consensus  was  reached  was  the 
subject  of  major  problems  in  the  personnel  information  system 
environment.  The  Workshop  concentrated  on  the  task  of  identifying  and 
enumerating  currently  existing  problems  in  the  Army's  personnnel 
information  systems  environment,  and  agreed  that  because  there  are  so 
many  problems  it  is  important  to  zero  in  on  the  single  problem  which  is 
the  root  of  all  the  other  problems.  This  simple  crucial  problem  is  the 
lack  of  an  organized,  disciplined,  and  systematic  approach  in  managing 
data  processing  in  the  Army.  Of  course,  the  Army  is  not  the  only 
organization  lacking  such  an  approach;  all  other  sectors  in  the  gover¬ 
nment  and  many  private  enterprises  are  probably  generally  a  victim  of 
the  same  problem  ...  nor  are  all  private  sector  organizations  to  be 
excluded. 

The  participants  agreed  that  the  problem  started  with  a  semantic 
inadequacy,  in  that  we  have  an  inability  to  define  what  a  system  is.  It 
is  generally  defined  very  loosely  as  any  collection  of  software  and/or 
hardware  operating  at  any  level.  The  participants,  however,  felt  a  need 
to  view  the  personnel  management  system  as  an  abstract  system  which 
deals  with  regulations,  procedures,  requirements,  etc.  Thus,  some 
particular  set  of  hardware  and  software  merely  represents  tools  that 
serve  and  support  that  system.  Yet,  in  practice,  we  tend  to  ignore  that 
distinction.  We  look  at  everything  that  is  hardware  and  software 
oriented  as  a  system.  When  we  take  this  viewpoint  for  a  system 
definition,  our  systems  become  poorly  managed,  exhibit  a  poor  design, 
and  appear  as  ad  hoc  evolutionary  creations.  Requirements  simply  arise 
and  evolve,  and  nobody  specifies  them  carefully  at  whatever  level  they 
happen  to  develop.  There  is  no  mechanism  for  placing  such  requirements 
in  a  priority  order. 

Therefore,  system  requirements  as  part  of  the  software  development 
cycle  continue  to  be  a  problem  within  the  Army  as  a  whole.  A  Detailed 
Functional  System  Requirement  (DFSR)  is  often  talked  about  but  never 
used.  Specification  of  requirements  and  validation  of  requirements  is 
rarely  carried  through.  This  results  in  system  designs  that  never  take 
into  account  that  they  will  ever  have  to  be  integrated.  This  in  turn 
makes  efforts  toward  standardization  difficult. 

The  consequence  of  all  this  is  that  there  is  no  determined  effort 
nor  are  there  resources  for  using  state-of-the-art  techniques.  Managers 
often  say,  "Why  isn't  this  system  on  line?"  Yet  the  systems  are  already 
saturated  operating  in  a  batch  mode  processing  serially.  How  are  they 
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going  to  be  able  to  do  interactive  on-line  processing?  Such  systems  can 
not  simply  be  modified  or  upgraded;  every  single  one  of  them  has  to  be 
totally  redesigned  to  become  on-line  to  utilize  data  base  management 
systems  and  concepts.  The  manpower  necessary  to  develop  the  software 
and  the  equipment  to  utilize  it  are  just  non-existent;  and  this  is  a 
serious  problem.  These  are  just  a  few  examples  of  the  lack  of  a 
determined  perception  that  the  whole  system  has  to  be  managed.  If 
managed,  then  it  is  managed  by  hundreds  of  separate  managers. 

Another  problem  is  the  relatively  low  level  of  user  participation. 
User  participation  occurs  too  far  back  in  the  development  stage  to 
significantly  influence  the  plan,  and  user  validation  of  requirements 
occurs  after  the  system  is  fielded.  On  the  other  hand,  there  are 
various  mitigating  factors  in  the  Army  situation.  First,  the  users  in 
the  corporate  structure,  no  matter  how  large,  are  relatively  closer  to 
each  other  than  are  users  in  the  Army,  particularly  in  the  case  of  the 
centrally  developed  systems  that  are  going  to  be  used  throughout  Europe 
or  all  over  the  world.  Secondly,  the  private  sector  has  a  unique 
capability  of  validating  the  success  or  failure  of  one  of  its  systems: 
a  year  or  so  after  a  system  is  launched,  if  it  is  not  producing  a 
profit,  you  know  that  it  is  wrong.  In  contrast,  systems  designed  for 
the  Army  are  not  intended  to  make  a  profit;  their  sole  purpose  is  to 
prepare  for  the  defense  of  the  country  in  time  of  war,  and  that 
fortunately  does  not  happen  too  often.  They  are  very  seldom  put  to  any 
real  test. 

Another  pervasive  problem  is  that  systems  can  not  meet  expansion 
requirements;  they  are  not  flexible  to  change  and  to  the  changing 
scenarios.  Existing  systems,  because  of  their  age,  are  batch¬ 
processing-oriented  and  fragmented;  they  can  not  be  integrated  to  meet 
the  operational  requirements.  The  consequence  of  all  these  problems  is 
that  many  managers  throughout  CONUS  are  designing  their  own  systems  as 
expediencies  to  support  local  decision-making  process,  and  this  is  the 
heart  of  the  problem.  As  a  result  of  not  going  anywhere  and  of  the 
difficulties  managers  have  encountered  with  existing  systems,  managers 
have  directed  supplementation  of  those  systems  with  systems  of  their 
own.  These  new  systems  are  operating  on  the  periphery. 

To  summarize,  the  Workshop  participants  agreed  on  the  following 
catalog  of  problems  in  the  current  environment  of  the  Army's  human 
resource  information  systems: 

*  Any  collection  of  hardware  and/or  software  which 
supports  one  or  more  functions  is  called  a  system. 

Many  of  these  systems  are  based  on  ad  hoc  requests 
with  little  or  no  specifications  and  no  pre¬ 
determined  interfaces  with  other  systems  and  are  not 
well  understood  by  their  users. 

*  Links  between  traditional  personnel  functions  and 
other  activities  (for  example,  finance)  are  not 
clearly  defined. 

*  There  is  a  lack  of  standardization  of  hardware, 
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software,  and  data  elements. 

*  There  is  no  determined  effort  or  ability  to  use 
available  state-of-the-art  technology  (for  example, 
telecommunications,  and  particularly  on-line 
systems/ . 

In  short  the  problem  is  that  there  is  in  general  a  serious  lack  of 
any  organized,  disciplined,  and  systematic  approach  to  the  management  of 
the  Army's  personnel  information  resource.  There  is  no  real  system. 

Proposed  System  Solution 


In  considering  the  task  of  charting  a  proposed  answer  to  the  Army's 
human  resource  management  information  needs,  the  Workshop  participants 
re-emphasized  the  urgency  of  correctly  identifying  the  basic  problems. 
As  can  be  seen  from  the  accompanying  diagram,  the  group  did  not  attempt 
to  identify  some  specific  solutions;  instead,  the  participants  focused 
their  concern  on  the  urgency  of  rationalizing  and  implementing  an  effec¬ 
tive  solution  process.  Thus,  in  the  opinion  of  the  Workshop 
participants,  the  real  solution  to  the  Army's  systems  design  problem  i6 
possible  only  by  getting  the  problem  clearly  identified  and  on  record. 
The  problem  has  to  be  written  down  in  a  way  that  will  be  understood  by 
managers  on  a  variety  of  levels.  What  the  Workshop  participants  felt 
had  to  be  done  was  to  identify  the  issues  faced  by  the  system  designers 
and  to  accurately  describe  whatever  requirements  had  to  be  met,  so  that 
the  solution  could  be  identified  in  terms  of  issues  and  guidelines  and 
be  produced  in  a  document.  The  document  should  be  prepared  by  an 
outside,  unbiased  agency,  and  should  be  provided  to  the  various  people 
in  the  personnel  community.  The  people  in  that  community  should  then  be 
able  to  address  these  issues  and  to  develop  a  plan  about  how  they  would 
integrate  their  system  and  needs  with  other  members  of  the  personnel 
community,  but  do  this  work  independently.  These  ideas  would  then  come 
up  to  a  local  body,  such  as  DCSFER,  that  would  review  these  individual 
plans.  At  that  point  the  individuals  should  be  assembled  in  a  con¬ 
ference  or  workshop  in  order  to  exchange  ideas  about  the  various  plans. 
This  would  result  in  a  multi-level  task  force  that  would  then  develop 
the  plan  of  action  to  go  about  integrating  these  systems.  This  multi¬ 
function  task  force  would  come  from  these  people  and  be  headed  up  by 
DCSPER,  and  would  include  staff  representatives,  top  line  staff,  and 
technical  personnel.  The  action  plan  itself  would  have  to  state  goals, 
identify  the  steps  to  accomplish  this  integration,  establish  priorities, 
and  identify  research  requirements  in  terms  of  dollars,  people,  and 
time.  There  are  on-going  organization  activities  to  test  the  existing 
systems.  If  these  turn  out  to  be  a  failure,  the  failure  itself  would 
hopefully  impact  these  guidelines  and  put  some  pressure  on  upper  levels 
of  management  to  make  some  changes. 

One  of  the  things  that  has  to  be  going  on  all  the  time  during  this 
process  is  public  relations.  The  idea  is  to  publicize  the  entire 
process,  by  saying:  "This  is  what  we  are  doing,  this  is  why  we  are 
doing  it,  and  these  are  the  issues."  It  is  absolutely  necessary  that 
all  of  the  members  of  the  Army  staff  and  organizations  are  aware  of  what 
is  going  on.  PR  would  be  a  key  element  in  the  search  for  a  successful 


PROPOSED  SOLUTION 


Page  34-A 


Public  Relations  (PR)  Conducted 
Throughout  Solution  Process 

PR 


* 


Action  Plan:  Goals 
Steps 

Priorities 

Resource  Requirements 


FIGURE  1 


Army  Personnel  Data  Sharing  Project  (FINAL  REPORT) 


Page  35 


system  solution. 

Of  course,  as  one  of  the  Workshop  participants  pointed  out,  there 
are  two  kinds  of  PR  involved.  One  is  concerned  with  what  is  being  done 
overall;  the  other  involves  individual  personalities.  Many  people  who 
are  doing  various  functions  will  be  leaving  those  functions  very 
shortly,  because  the  longest  they  stay  is  generally  two  years.  Each 
individual  must  recognize  a  short  term  set  of  goals  that  are  achievable 
during  his/her  tenure  that  provide  management  actions  which  will 
contribute  to  the  long  term  solution  of  personnel  problems.  This  will 
fulfill  the  second  kind  of  public  relations.  The  emphasis  by  the  Work¬ 
shop  participants  on  PR  and  on  the  problem  definition  indicates  that 
what  is  proposed  is  not  a  solution  in  the  typical  sense  of  the  word. 
That  is  to  say,  there  is  no  proposal  here  for  some  kind  of  integrated 
data  base  that  is  going  to  meet  all  needs.  One  of  the  conclusions 
reached  at  the  Workshop  is  that,  technologically,  there  are  paths  to  a 
solution,  and  that  the  technological  aspects  of  the  problem  are 
relatively  simple  compared  to  the  organisational  and  planning  problems. 
The  first  step  is  to  determine  what  process  is  required  to  get  the  job 
done,  and  this  includes  all  the  relevant  issues.  The  word  "relevant"  is 
important.  The  Workshop  participants  did  not  feel  it  appropriate  that 
commanders  be  asked  questions  about  what  they  think  about  coamon  data 
bases  and  other  technical  matters;  commanders  should  focus  their  atten¬ 
tion  on  whether  they  think  they  can  mobilize  in  time  of  war,  and  other 
such  problems  directly  relevant  to  their  conmand  positions. 

Another  point  is  that  the  probability  that  something  will  be  done 
about  this  is  very  low.  In  times  of  crises,  something  will  be  done 
about  it,  but  it  will  probably  be  sporadic.  Probably  the  wrong  things 
will  be  done.  A  very  valuable  contribution  of  this  process,  therefore, 
will  be  an  action  plan  well  thought  out  in  time  of  peace,  with 
involvement  of  all  different  factions:  such  a  plan  must  be  stepped  out, 
must  have  priorities,  and  must  be  given  resources.  Even  if  the  plan 
lays  on  the  shelf  for  years,  it  is  still  an  action  plan  that  could  be 
put  in  place.  Some  frame  of  it  could  at  least  be  used  in  time  of 
crisis. 

The  Workshop  participants  agreed  that  if  Proud  Spirit  turned  out  to 
be  a  failure,  that  would  be  the  time  to  start  the  PR.  PR  should  begin 
as  soon  as  you  recognize  that  there  is  a  problem,  and  this  should 
continue  all  through  the  system  development  process.  Of  course,  one 
difficulty  involved  with  such  an  exercise  has  to  do  with  establishing 
the  criteria  for  success  or  failure.  For  example,  there  were  many 
systems  problems  identified  two  years  ago,  and  those  problems  have  since 
been  solved.  The  test  may  now  be:  "Did  you  solve  those  problems?”. 
Another  difficulty  is  that  the  criteria  for  true  success  is  high. 

As  the  Workshop  proceeded,  attention  of  the  participants  turned  to 
the  difficulties  of  coonunication  among  the  various  components  of  the 
Army  personnel  community,  and  the  complexity  of  the  problem  seemed  so 
great  that  some  of  the  participants  questioned  "whether  we  know  what  we 
are  really  trying  to  solve".  But  the  final  consensus  was  a  re-emphasis 
of  the  fact  that  a  real  and  lasting  solution  to  the  problem  would  come 
only  through  the  development  and  implementation  of  the  solution  process 
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that  would  facilitate  full  exploration  of  all  the  problems  and  that 
would  address  organizational  weaknesses  which  were  identified  during  the 
Workshop.  As  one  participant  expressed  it: 

"I  think  we  do  know  what  we  are  trying  to  solve;  we  are 
trying  to  solve  the  conditions  which  impede  a  successful 
technical  solution.  If  we  go  back  to  the  problem  statements 
developed  earlier,  we  see  that  we  don't  have  a  flexible 
system  that  is  responsive  and  flexible.  The  solution  then  is 
to  develop  a  system  which  has  these  characteristics,  and  the 
only  way  to  develop  such  a  system  is  by  first  developing  a 
plan  for  defining  the  requirements.  The  first  important  end- 
product  is  a  careful  and  accurate  definition  of  the  defined 
requirements." 

In  general,  whereas  industry  is  building  state-of-the-art  informa¬ 
tion  systems  to  support  its  needs,  the  Army  has  only  pieces  of  informa¬ 
tion  systems  that  qualify  as  state-of-the-art.  In  many  cases  these 
information  systems  as  a  whole  are  not  responsive  to  the  Army's  needs. 
To  get  responsiveness,  the  pieces  need  to  be  integrated  into  a  whole. 
The  Workshop  participants,  after  considering  the  problems,  concluded 
that  the  real  problems  were  actually  organizational  and  financial  rather 
than  purely  technical.  In  some  cases  the  technical  problems  have 
already  been  resolved.  Hardware  issues  are  not  the  problem.  The  core 
of  the  problem  is  principally  non-technical,  and  any  action  on  the 
problem  should  be  directed  at  making  the  issues  known  to  key  personnel 
in  the  Army. 

Impediments  to  System  Development 

The  Workshop  participants  came  to  a  consensus  on  the  following 
inventory  of  impediments  which  must  be  overcome  by  designers  tasked  with 
the  development  of  the  human  resource  information  management  system  for 
the  Army: 


1.  Lack  of  leadership  that  is  able  to  perceive  the 
true  issues  and  problems  and  that  is  both  desirous  of 
and  responsible  for  solving  them;  i.e.,  there  is  no 
single  person  in  charge. 

2.  Excessive  organizational  and  mission  diffusion 
within  the  human  resource  management  information  area, 
characterized  by 

a.  Parochial  interest  of  separate  commands. 

b.  Perceived  loss  of  ownership  of  data  bases. 

c.  Problems  in  coordination  and  tasking. 

3.  Excessive  procurement  and  implementation  time  and 
cost. 


4.  Lack  of  planning,  along  with  the  propensity  to 
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"put-out-fires";  insufficient  vision,  courage,  commit¬ 
ment,  and  understanding. 

3.  Inability  to  define  functional  requirements.  The 
Army  is  not  organized  under  the  functional  sub¬ 
definitions  of  manning  (i.e.,  recruitment,  training, 
assignment/distribution,  sustainment,  separation),  and 
this  causes  reluctance  to  plan  and  an  inability  to 
define  functional  requirements. 

Thus,  the  greatest  impediment  is  that  there  is  no  one  person  in 
charge  of  the  entire  human  resources  management  information  arena; 
instead,  there  are  numerous  organizations,  none  of  which  are  under  the 
same  person  with  the  same  kind  of  mission.  Those  organizations  should 
either  be  placed  all  under  essentially  one  command  or  at  least  they 
should  be  given  a  single  focus.  Currently  there  are  organizations  such 
as  MILPERCEN,  DCSPER,  etc.,  all  pointed  at  different  targets.  As  a 
result,  the  human  resource  management  information  system  is  not 
cohesive.  Action  is  not  taken  for  the  benefit  of  the  whole.  The 
various  Army  organizations  act  for  their  own  self-interests. 

However,  in  addition  to  these  political  or  organizational 
impediments,  another  very  real  impediment  is  the  excessive  procurement 
and  implementation  time  in  the  military.  This  time  somehow  must  be 
shortened.  There  are  of  course  various  people  working  on  this  problem, 
and  hopefully  they  will  be  successful  in  solving  it. 

Plan  for  Action 

The  Workshop  participants  came  to  a  consensus  on  the  need  to 
develop  a  planning  framework  that  would  feature  a  further  study  effort 
to  determine : 


-  Feasibility 

-  Resource  Requirements 

-  Organizational  Impact 

-  Alternative  Solutions 

-  Mission  Area  Analysis 

The  outlines  of  such  a  planning  framework  are  presented  in  the  following 
section  of  this  report. 
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SECTION  VI. 

CONCLUSIONS  AND  RECOMMENDATIONS 


The  research  conducted  under  this  contract  has  identified  and  sum¬ 
marized  many  issues  which  affect  the  manner  in  which  human  resource 
information  is  managed  for  the  Army.  It  is  clear  that  there  are  many 
people  and  organizations  concerned  with  improving  the  management  of 
human  resource  information. 

MOBEX-80  revealed  significant  progress  over  MOBEX-78  and  spoke  well 
for  the  perseverance  and  determination  of  the  entire  human  resource 
information  community.  However,  it  also  underscored  some  of  the  obser¬ 
vations  expressed  earlier  in  this  report: 

*  The  obsolescence  of  the  Army's  "automated"  person¬ 
nel  system  not  only  impacts  its  day-by-day  operation 
but  almost  precludes  any  true  mobilization  effort. 

*  Human  resource  information  policies  must  be  formed 
which  eliminate  the  fragmentation  of  personnel  data 
and  which  anticipate  mobilization. 

The  significance  of  these  generic  issues  is  borne  out  by  the 
problems  which  emerged  at  the  RCPAC-MILPERCEN  interface  under  MOBEX-80. 
These  problems  made  it  emphatically  clear  that  if  a  Human  Resource 
Information  Data  Base  is  to  serve  both  peacetime  and  wartime  and  is  to 
serve  both  the  reserve  command  and  the  Active  Army,  etc.,  the  data  base 
must  contain  all  of  the  data  needed  by  each  organization.  In  addition, 
the  data  needed  by  each  organization  must  be  available  to  that  organiza¬ 
tion  at  the  time  needed  and  must  be  under  the  control  of  that  or¬ 
ganization.  Finally,  the  only  data  which  should  flow  from  one  organiza¬ 
tion  to  the  other  is  the  data  needed,  at  the  time  needed,  for  the  func¬ 
tion  requiring  it. 

For  instance,  under  current  circumstances,  upon  mobilization,  there 
is  supposed  to  be  a  flow  of  records  from  RCPAC  to  MILPERCEN.  This 
process  has  major  system  flaws: 

*  The  data  maintained  by  RCPAC  is  for  RCPAC 
activities  and  is  maintained  pursuant  to  Reserve 
Command  rules  and  requirements  which  are  not 
congruent  with  Active  Army  requirements. 

*  The  number  of  records  (even  if  it  met  Active  Army 
requirements)  which  flow  from  reserve  status  to 
active  status  is  very  much  larger  than  that  set  of 
active  records  maintained  for  peacetime. 

*  When  the  flow  of  records  is  complete,  the  data 
processing  resources  of  the  Reserve  Conmand  are 
empty  and  the  data  processing  resources  of  the 
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Active  Army  are  glutted. 

This  situation  leads  to  a  major  paradox  which  characterizes  the 
whole  question  of  peacetime  vs.  wartime  information  processing  demands. 
If  the  data  processing  resources  of  the  Active  Army  are  sufficient  to 
absorb  the  Reserve  Command  data,  they  go  unused  during  peacetime.  Con¬ 
versely,  the  Reserve  Command  Resources  stand  to  be  empty,  disjoint,  and 
difficult  to  use  during  wartime. 

What  is  needed  is  a  structure  or  system  in  which  personnel  data  is 
maintained  in  readiness  and  available  for  all  purposes.  Again  using  the 
reserve  command  issues  as  an  example,  if  the  needed  personnel  data  were 
maintained  on  a  basis  such  that  the  record  was  the  same  for  both  reserve 
and  active  status,  it  would  only  be  necessary  to  set  a  status  indicator 
to  mobilize  the  record.  If  the  records  were  maintained  at  appropriate 
mobilization  centers  and  if  the  reserves  were  instructed  as  to  which 
center  to  report,  mobilization  records  would  be  complete  by  the  time  the 
troops  arrived. 

This  scenario  is  of  course  predicated  on  the  notion  that 
"readiness"  in  the  Army's  business  and  that  data  required  to  operate  a 
peacetime  Army  is  a  superset  of  the  data  required  to  operate  a  wartime 
Army.  Readiness  further  implies  the  ability  to  demobilize  without  loss 
of  important  data  or  a  state  of  readiness.  While  demobilization  may  not 
be  as  time  critical  as  mobilization,  it  should  be  expeditious  in  order 
to  preserve  readiness  and  to  maintain  morale. 

Since  soldier's  records  (active  and  inactive)  are  never  static,  it 
is  necessary  to  maintain  both  the  integrity  of  the  record  and  the 
integrity  of  the  data  which  identifies:  where  the  record  is;  where  it 
and  the  soldier  are  going;  when  they  will  arrive;  etc.  Therefore, 
consider  a  model  in  which  we  include  military  facilities  in  which  sol¬ 
diers  records  are  maintained.  From  the  point  of  view  of  the  reserve 
command,  these  are  mobilization  centers.  The  data  on  reservists  marked 
inactive  are  maintained  for  reserve  command  purposes.  The  data 
maintained  on  active  soldiers  are  a  subset  of  the  reserve  data.  During 
peace  time,  if  a  reservist  is  assigned  to  a  different  mobilization 
center,  his  entire  record  is  transferred  with  him  to  that  center;  if  an 
active  soldier  is  transferred  to  a  different  military  facility,  his 
active  records  are  transfered  to  the  next  facility.  Upon  mobilization, 
reserve  records  are  marked  active  and  when  the  soldier  arrives,  he  and 
that  data  pertinent  to  his  next  assignment  are  dispatched  to  his  new 
post.  The  remainder  of  his  records  are  maintained  at  his  mobilization 
center  and  the  control  center  receives  data  indicating  where  both  sets 
of  data  reside.  While  the  soldier  is  on  active  status,  his  active 
records  go  with  him.  Upon  demobilization  the  control  center  knows  where 
both  sets  of  records  reside  and  if  the  soldier  is  mustered  out  at  a 
location  other  than  his  mobilization  center,  all  records  are  dispatched 
to  his  new  mobilization  center. 

Such  a  system  is  technologically  attainable.  To  those  people  who 
have  endured  the  bureaucratic  complexities  and  delays  which  have  for  so 
long  precluded  such  a  system,  it  may  sound  utopian,  but  it  is  utopian 
only  in  the  sense  that  it  is  inevitable  -  it  is  the  only  way  to  go  if 
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the  Army  is  to  respond  to  the  information  processing  challenges  of  the 
present  and  the  future. 

However,  the  fact  remains  that,  while  one  can  design  and  prescribe 
such  a  system  on  paper,  the  Army  is  still  not  in  a  position  to  answer 
many  important  questions  needed  by  managers  whose  decisions  and  careers 
hang  in  the  balances  of  rapidly  changing  technology.  For  instances,  the 
very  size  of  the  needed  system  exceeds  anything  currently  operating  in 
the  private  sector.  The  enormity  of  the  system  raises  such  questions 
as : 


*  What  database  management  system  should  be  used? 

*  Given  the  multiplicity  of  users,  how  should  the 
data  be  organized? 

*  Under  a  distributed  data  system,  would  AUTODIN  II 
allow  for  satisfactory  response? 

*  Under  a  centralized  data  system,  would  AUTODIN  II 
support  satisfactory  comnunications  response? 

*  Under  a  centralized  data  system,  how  large  a  com¬ 
puter  would  be  required? 

*  Under  a  centralized  data  system,  what  sort  of  a 
network  of  computers  might  be  required? 

*  Under  a  distributed  data  system,  what  sort  of  a 
network  of  computers  would  be  required  at  each  node 
to  provide  required  reliability? 

*  Under  a  distributed  data  system,  what  would  be  the 
nature  of  the  control  and  archival  center?  How 
large  and  how  many  computers  would  be  required? 

Without  some  performance  data  to  support  particular  design  choices, 
bureaucrats  have  no  choice  but  to  defend  turf.  What  is  needed  is  a  body 
of  research  sponsored  at  the  DCSPKRS  level.  This  research  should 
generate  empirical  data  regarding  such  phenomena  as  the  performance 
characteristics  of  existing  DBMS  packages  operating  in  an  environment  of 
several  million  personnel  records  being  accessed  according  to  a  variety 
of  scenarios,  such  as  a  scenario  characterized  by  distributed  data, 
distributed  data  usage,  and  central  control;  one  characterized  by 
central  data,  central  control,  and  distributed  data  usage;  etc. 

Figures  2  and  3  illustrate  the  two  primary  system  concepts  which 
appear  to  meet  the  Army's  HRIDB  needs.  Figure  2  is  based  on  the  concept 
of  a  distributed  data  model  which  assumes  the  need  for  a  central  system 
which  does  not  have  real  time  needs  for  the  detailed  data  maintained  at 
the  various  military  facilities.  It  does  however  have  need  for 
aggregated  data  for  performance  monitoring,  etc.  It  also  possesses  the 
data  which  describes  the  HRIDB  in  terms  of  what  is  located  where.  For 
instance,  suppose  that  upon  mobilization,  some  reservist  cannot  report 
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to  his  assigned  mobilization  center.  When  he  appears  at  an  alternate 
center,  the  control  center  should  be  able  to  locate  and  move  his  records 
to  the  location  at  which  he  has  appeared.  The  central  control  site 
would  have  knowledge  of  all  troop  movements  and  would  synchronize  all 
record  movements,  etc. 

Figure  3  illustrates  how  a  completely  centralized  data  and  control 
system  might  work.  For  the  case  of  the  reservist  reporting  to  a 
mobilization  center  other  than  the  one  assigned  him,  it  would  only  be 
necessary  to  modify  his  location  indicator  rather  than  move  his  record. 
All  troop  movements  would  still  be  managed  on  a  central  control  basis. 

An  interesting  alternative  to  figure  3  would  be  a  system  in  which 
the  central  facility  is  actually  a  network  of  computers  wherein  a  given 
computer  and  data  base  act  like  a  distributed  processing  center 
dedicated  to  a  specific  military  facility  or  mobilization  center.  The 
same  controls,  record  movements,  etc.  would  take  place  within  a  local 
network  rather  than  a  network  of  remotely  located  centers. 

The  viability  of  such  conceptual  systems  is  clear.  But  how  does 
one  choose  among  them?  A  responsible  decision  maker  has  many  questions 
which  cannot  be  answered  with  respect  to  tradeoffs,  benefits,  etc. 
Decision  support  data  is  needed.  Military  planning  and  implementation 
operate  in  a  complex  bureaucratic  milieu  which  demands  that  choices  be 
supported  by  data.  The  House  Government  Operations  Conmittee,  the  House 
Appropriations  Committee,  the  General  Services  Administration,  the 
Office  of  Management  and  Budget,  the  General  Accounting  Office  and  a 
myriad  of  Defense  organizations  have  to  be  convinced  with  data  and 
appropriate  audit  trails  that  choices  which  result  in  multi-million  dol¬ 
lar  procurements  have  been  based  on  good  data  and  that  such  complex 
systems  have  a  high  probability  of  success.  This  kind  of  data  simply 
does  not  exist.  This  calls  for  a  research  effort  to  produce  and 
evaluate  such  data.  Such  a  research  program  can  be  outlined  as  follows: 

Given  that  the  (active/ inactive)  OMF/KMF  files  are  to  be 
integrated  and  have  been  specified,  identify  what  additional 
data  would  be  required  to  integrate  RCPAC  records  with  those 
of  MILPERCEN: 

(a.)  Investigate  and  identify  transformation 
procedures  which  would  permit  these  files  to  be 
integrated.  Obviously,  some  troops  on  active  duty 
have  records  in  RCPAC;  some  troops  on  reserve  duty 
have  records  archived  in  MILPERCEN;  some  troops  have 
achieved  reserve  status  without  an  active  Army 
record,  etc. 

(b.)  Given  the  structure  and  quantity  of  these  data, 
develop  a  set  of  records  (without  violation  of 
privacy,  individual  rights,  etc.)  which  truly 
characterize  the  Army  HRIDB  as  it  now  stands.  (As 
used  here,  a  data  base  is  a  simple  collection  of 
records  possessing  attributes.) 
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(c.)  From  the  set  of  standard  DBMS's  commercially 
available,  identify  those  that  accomodate  the 
quantity  of  data  involved.  If  none  exist, 
investigate  the  modifications  needed  for  those  which 
provide  the  closest  fit. 

(d.)  Select  the  DBMS  which  supports  the  activities 
which  follow  and  build  the  data  base  needed  to  sup¬ 
port  the  research  to  be  performed. 

(e.)  Characterize  the  Army  which  will  exist  after 
mobilization.  For  instance,  the  set  of  active 
records  of  troops  with  less  than  six  months  service 
might  well  profile  (demographically  and  otherwise) 
the  troops  to  be  accessioned  via  the  draft.  Build  a 
set  of  records  of  sterotypes  of  the  size  needed  for 
actually  simulating  the  data  handling  requirements  of 
a  mobilized  Army. 

(g.)  Select  the  DBMS  best  suited  for  performing 
analysis  on  such  a  body  of  records. 

(h.)  From  the  fifty  or  so  SIDPERS  facilities, 
identify  those  which  could  best  serve  as  mobilization 
centers.  From  the  set  of  sterotype  records,  identify 
the  set  of  records  to  be  maintained  at  each  mobiliza¬ 
tion  center  under  a  distributed  data  model. 

(i.)  Take  the  largest  of  these  distributed  sets  of 
data  and  identify  the  set  of  DBMS's  which  can  accom¬ 
modate  this  amount  of  data. 

(j.)  Take  the  total  HRIDB  and  identify  the  set  of 
DBMS's  which  can  accomodate  this  amount  of  data. 

(k.)  Identify  the  structural  constraints  imposed  by 
each  of  the  DBMS's  for  each  of  the  sets  of  data  in 
(i.)  and  (j.)  above. 

(1.)  Install  the  data  bases  of  (i.)  and  (j.)  under 
the  constraints  of  (k.)  on  a  single  computer  of 
appropriate  capacity  for  each  case. 

(m.)  Generate  a  "Standard  Typical"  set  of 
query/update  scenarios  and  run  these  against  each 
system  and  data  base.  Measure  response  as  a  function 
of  load. 

(n.)  Rank  each  DBMS  with  respect  to  flexibility, 
maintainabilty,  responsiveness,  etc. 

(o.)  Select  the  DBMS  best  suited  to  the  HRIDB. 

(p.)  Develop  simulation  scenarios  wherein  the  total 
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central  HRIDB  resident  on  one  computer  or  tightly 
coupled  set  of  computers  is  simulated  by  a  computer 
dedicated  to  creating  a  mobilization  simulation.  The 
stimulator  would  also  record  and  report  response 
data,  errors,  etc. 

(q.)  Identify  and  install  on  the  necessary  number  of 
mobilization  center  computers,  the  appropriate  seg¬ 
ment  of  the  HRIDB.  From  this  distribution  identify 
the  set  of  "control  data"  needed  to  manage  a 
distributed  data  system  with  central  knowledge  of  the 
content  of  each  mobilization  center.  This  will  of 
course  require  a  complete  network  of  computers. 

Using  such  a  network,  simulate  a  mobilization  exer¬ 
cise. 

(r.)  Throughout  the  above  activities  identify  and 
report  data  and  trends  which  may  be  important  to 
decision  makers  responsible  for  maintaining  human 
resource  information  for  the  Army. 

This  list  of  proposed  research  activities  illustrates  the  scope  and 
nature  of  the  work  needed  to  be  done  in  a  research  atmosphere  indepen¬ 
dent  of  operational  necessities.  A  major  problem  faced  by  the  Army  now 
is  that  operational  units  are  being  asked  to  make  decisions  and  commit¬ 
ments  in  the  absence  of  much  needed  data.  Each  of  the  tasks  outlined 
above  is  such  a  significant  effort  that  a  commitment  at  the  DCSPERS 
level  to  support  research  of  this  sort  is  needed  in  order  to  generate 
data  that  will  support  planning  throughout  the  human  resource  community. 
The  kind  of  data  and  experience  called  for  in  the  above  list  of  tasks 
simply  will  not  come  from  the  private  sector. 

The  following  sunmary  of  recommendations  is  consistent  with  the 
findings  of  the  Georgia  Tech  research  team  and  with  the  workshop  fin¬ 
dings  as  summarized  in  the  "proposed  solution"  extended  to  provide  a 
mechanism  for  generating  decision  support  data  through  the  recommended 
research  program  in  order  to  sustain  the  planning  and  implementation 
processes  of  the  Army. 
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SUMHARY  OF  RECOMMENDATIONS 

In  summary,  we  recommend  that  DCSPERS  employ  a  planning  framework 
which  embodies  the  following: 

GOALS 

*  Eliminate  the  obsolescence  of  the  Army's  "automated"  per¬ 
sonnel  systems. 

*  Establish  and  enforce  human  resource  information  policies 
which  eliminate  the  fragmentation  of  personnel  data  for 
whatever  purpose:  peacetime,  wartime,  etc. 

DEVELOPMENT  PLAN 

*  Establish  a  continuing  program  of  HRIDB  research  which 
will  support  decision  makers  who  must  contend  with  the 
intricacies  of  government  management  (particularly  computer 
procurements). 

*  Establish  a  management  strategy  baaed  on  current 
knowledge.  Anticipate  that  current  knowledge  will  be 
altered  by  HRIDB  research  results: 

-  develop  functional  specifications  based  on 
current  perception  of  an  integrated  personnel  data 
management  system  such  as  has  been  described  in 
general  terms  in  this  section. 

-  develop  a  schedule  of  events  leading  toward  the 
goal  of  eliminating  obsolescence;  for  instance, 
first  eliminate  hardware  obsolescence,  move  from 
batch  processing  to  on-line  data  acquisition 
control  and  reporting,  etc.  This  will  involve  per¬ 
sonnel  development,  training,  etc. 

Initiate  and  sustain  whatever  organizational 
changes  are  needed  to  comply  with  a  policy  which 
eliminates  the  fragmentation  of  the  Army's  human 
resource  information  data. 

*  Develop  a  program  of  education  and  public  relations  within 
the  Army  which  supports  this  development  plan. 

These  recommendations  are  consistent  with  the  findings  of  the  Geor¬ 
gia  Tech  research  team  and  with  the  workshop  findings  as  summarized  in 
the  "proposed  solution";  but  they  extend  these  findings  and  the  solution 
proposed  therein  by  providing  a  mechanism  for  generating  decision  sup¬ 
port  data  through  the  recomnended  research  program  in  order  to  sustain 
the  planning  and  implementation  processes  of  the  Army. 


